[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC v1 01/15] iommu: Add iommu_intpost to control VT-d Posted-Interrupts feature
>>> On 26.03.15 at 18:39, <andrew.cooper3@xxxxxxxxxx> wrote: > On 25/03/15 12:31, Feng Wu wrote: >> @@ -51,6 +52,7 @@ bool_t __read_mostly iommu_passthrough; >> bool_t __read_mostly iommu_snoop = 1; >> bool_t __read_mostly iommu_qinval = 1; >> bool_t __read_mostly iommu_intremap = 1; >> +bool_t __read_mostly iommu_intpost = 0; >> bool_t __read_mostly iommu_hap_pt_share = 1; >> bool_t __read_mostly iommu_debug; >> bool_t __read_mostly amd_iommu_perdev_intremap = 1; >> @@ -94,7 +96,11 @@ static void __init parse_iommu_param(char *s) >> else if ( !strcmp(s, "qinval") ) >> iommu_qinval = val; >> else if ( !strcmp(s, "intremap") ) >> + { >> iommu_intremap = val; >> + if ( iommu_intremap == 0 ) >> + iommu_intpost = 0; >> + } >> else if ( !strcmp(s, "debug") ) >> { >> iommu_debug = val; > > At no point here do you add an strcmp(s, "intpost"), which means that > you do not alter the allowable command line syntax. > > intpost must be able to be controlled independently of intremap, so I > suggest > > else if ( !strcmp(s, "intpost") ) > iommu_intpost = val; > > and after the while loop, > > if ( !iommu_intremap ) > iommu_intpost = 0; > > To ensure that intpost is never 1 if intremap is 0. That shouldn't be after the while loop, but elsewhere such that intremap getting turned off for other reasons or even being switched to a default of zero would still result in consistent settings. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |