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

[Wei Wang <wei.wang2@amd.com>]

Am 12.06.2012 18:43, schrieb Jan Beulich:
>>>> On 12.06.12 at 18:08, Andrew Cooper<andrew.cooper3@citrix.com>  wrote:
>> On 12/06/12 16:13, Jan Beulich wrote:
>>>>>> On 12.06.12 at 14:02, Wei Wang<wei.wang2@amd.com>  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@xmission.com>
>>>>     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 sounds absolutely good to me. thanks for the suggestion.

> 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.

Cool! thanks for doing that. Looking forward to it in Xen 4.2 since 
iommu msi is really broken with recent Linux dom0...

Thanks
Wei


>> ( 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
>
>