From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Wang Subject: Re: [PATCH V2] amd iommu: re-enable iommu msi if dom0 disabled it Date: Thu, 14 Jun 2012 17:15:52 +0200 Message-ID: <4FDA0028.3090609@amd.com> References: <4FD72FE4.80009@amd.com> <4FD778C802000078000897EF@nat28.tlf.novell.com> <4FD76976.2020203@citrix.com> <4FD78DE6020000780008986D@nat28.tlf.novell.com> <4FD9D559.9050206@amd.com> <4FDA0ECD0200007800089FEA@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4FDA0ECD0200007800089FEA@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Andrew Cooper , Jeremy Fitzhardinge , "xen-devel@lists.xensource.com" , "Hurwitz, Sherry" , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org Am 14.06.2012 16:18, schrieb Jan Beulich: >>>> On 14.06.12 at 14:13, Wei Wang 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 > >