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

[Wei Wang <wei.wang2@xxxxxxx>]

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
> code...
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.
Thanks,
Wei

> Jan


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