[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 14.06.2012 16:18, schrieb Jan Beulich:
On 14.06.12 at 14:13, Wei Wang<wei.wang2@xxxxxxx> wrote:
Am 12.06.2012 18:43, schrieb Jan Beulich:
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...
That's unlikely to be for 4.2 - it's going to have a reasonable risk
of regressions, and functionality like that I don't think is nice to
rush into a feature frozen tree, the more that it provides a
workaround for the combination of questionable design and an
improper kernel side fix.
Yes, it looks like improper to me also, but it would also be nice to
have something Xen to handle this situation. Maybe we should not trust
guest os, even dom0 some times...
Have you at all considered getting this fixed on the kernel side?
As I don't have direct access to any AMD IOMMU capable
system - can one, other than by enumerating the respective
PCI IDs or reading ACPI tables, reasonably easily identify the
devices in question (e.g. via vendor/class/sub-class or some
such)? That might permit skipping those in the offending kernel
AMD IOMMUs (both v1 and v2) uses class id 08 (System Base Peripheral)
and sub class id 06 (IOMMU). Combined with PCI_VENDEOR_ID_AMD, this
should be enough to identify amd iommu device. I could send you a kernel
patch for review using this approach. I would believe that fixing this
issue in 4.2, no matter how, is really important for amd iommu.
Xen-devel mailing list