Re: [Xen-devel] [PATCH V2] x86/AMD-Vi: Add additional check for invalid special->handle

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 29.08.13 at 22:26, Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx> 
>>> wrote:
> On 8/29/2013 2:17 AM, Jan Beulich wrote:
>> As said in a previous reply - I'm convinced we can't fix things both
>> ways with just a single command line option: We need to know
>> which value to use as anchor (I'd generally think that ought to be
>> the value inside the square backets) and which value to use as
>> overrides.
>>
>> And since my earlier patch was inspired by the Linux one - I don't
>> think Linux allows fixing up things the way you try to here either.
>>
> Actually, on Linux, the it would try matching the handle (i.e. the value 
> in the square bracket).  If it is specified via command line, it will 
> override the value in the IVRS.

Right - that's matching the behavior of my patch. Or am I missing
something here?

> In case the entry contains the handle 
> value which is not list as IOAPIC in the ACPI APIC table, we should be 
> able to invalidate the entry.  This same rule should also apply when 
> users specify invalid handle value.  Also, I never see the case where 
> the special->used_id is incorrect. The other case I am seeing is when 
> the IVRS special entry is missing for IOAPIC, which this should already 
> be handled in your original patch.
> 
> I have also verified that this works on Linux.  For example, on my 
> system, there are 2 IOAPICs with APIC ID 8 and 9 according to the ACPI 
> APIC table.  However, in IVRS, the value in both special entries are 
> 0xff.  When I give the boot options "ivrs_ioapic[8]=00:14.0 
> ivrs_ioapic[9]=00:0.1", this allows IOMMU to initialize correctly.

Yes, because you specify the _full_ set. But we've seen many cases
(like Sander's) where one of the IVRS entries is correct and the other
isn't. In that case specifying one command line option should be
sufficient, and fixing it in the direction you propose requires - as said -
a second command line option, anchored at other than the IO-APIC ID.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel