[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.