Re: [Xen-devel] [PATCH V2] amd iommu: re-enable iommu msi if dom0 disabled it

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 12.06.12 at 18:08, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> On 12/06/12 16:13, Jan Beulich wrote:
>>>>> On 12.06.12 at 14:02, Wei Wang <wei.wang2@xxxxxxx> wrote:
>>> I had attached a revised patch, please check it.
>> While the patch technically looks better now, you didn't eliminate
>> my objections to the approach you take, nor did you comment on
>> the proposed alternative.
>>
>> A fundamental problem is that your IOMMUs show up as a "normal"
>> PCI devices, breaking the separation between what is being
>> managed by the hypervisor vs by the Dom0 kernel. (This even
>> allows something as odd as passing through an IOMMU to a
>> DomU, which would clearly upset the hypervisor.)
>>
>>> I found that the following Linux commit triggers this issue. It has been 
>>> included into 3.4 pv_ops.
>>>
>>> " commit a776c491ca5e38c26d9f66923ff574d041e747f4
>>>    Author: Eric W. Biederman <ebiederm@xxxxxxxxxxxx>
>>>    Date:   Mon Oct 17 11:46:06 2011 -0700
>>>
>>>    PCI: msi: Disable msi interrupts when we initialize a pci device "
>> Thanks for locating this. As it stands, it is incomplete though
>> anyway: If the kexec-ed kernel is one built without CONFIG_PCI_MSI,
>> it won't have a means to suppress the "screaming" interrupts.
> 
> I feel that the correct solution would be for Xen to hide the PCI
> devices from dom0.  Xen already hides the DMAR ACPI table (by turning it
> to an XMAR table), and this would be the logical way to proceed now that
> IOMMU internals are appearing as PCI devices.

That is precisely what I suggested in my response to the first
version of this patch, and I'd also volunteer to look into putting
together a first draft implementation if we sort of agree that
this is the way to go.

> ( A similar issue comes into play now that newer generations of CPUs are
> exposing CPU internals as PCI devices )

Indeed, good point. Might be a little tricky though to determine
which one(s) they are, and still avoid conflicting with things like
the EDAC drivers in Dom0.

Jan


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