[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH V2] amd iommu: re-enable iommu msi if dom0 disabled it
Am 12.06.2012 18:43, schrieb Jan Beulich:
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 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...
( 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.
Xen-devel mailing list