Re: [Xen-devel] [PATCH] VTd/dmar: Tweak how the DMAR table is clobbered

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.04.15 at 18:44, <kevin.tian@xxxxxxxxx> wrote:
>>  From: Andrew Cooper [mailto:andrew.cooper3@xxxxxxxxxx]
>> Sent: Tuesday, April 14, 2015 5:09 PM
>> On 14/04/15 08:50, Jan Beulich wrote:
>> > Unless Kevin or
>> > Yang object, I'd therefore suggest reverting the change. Once
>> > we determined why VT-d needs what AMD Vi doesn't need, and
>> > once we settled on the risk of name collision (perhaps using an
>> > underscore prefixed name would further reduce this risk), we could
>> > then do this another way (zap the table from XSDT/RSDT instead?),
>> > or leave it as it was without the change.
>> 
>> It is my hope that this can be resolved in the longterm without any
>> modification to the acpi tables.  Currently, it is not possible to dump
>> the ACPI tables from dom0 without knowing how to hexedit the XMAR table
>> back into life.  This is an impediment to debugging.
>> 
>> However, I still believe that the current change is a positive
>> improvement over what happened previously.
> 
> I'm OK with this patch itself as it does improve current situation a bit,
> though we do need to figure out the mysterious reason why AMD doesn't
> require same hack. My gut-feeling is that hypervisor has to do something
> so an unmodified dom0 iommu driver is not activated to use iommu, unless
> the dom0 iommu driver has some awareness to give up proactively. 

There should be no such thing like an unmodified Dom0 IOMMU driver,
as Dom0 can't be HVM (and if it was HVM, it would necessarily have to
see other than the host's ACPI tables). My impression is that this was
solely added as a workaround by someone too lazy to adjust the Dom0
IOMMU driver back when the functionality was added.

Jan


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