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 14:13:13 +0200 Message-ID: <4FD9D559.9050206@amd.com> References: <4FD72FE4.80009@amd.com> <4FD778C802000078000897EF@nat28.tlf.novell.com> <4FD76976.2020203@citrix.com> <4FD78DE6020000780008986D@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: <4FD78DE6020000780008986D@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" , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org Am 12.06.2012 18:43, schrieb Jan Beulich: >>>> On 12.06.12 at 18:08, Andrew Cooper wrote: >> On 12/06/12 16:13, Jan Beulich wrote: >>>>>> On 12.06.12 at 14:02, Wei Wang 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 >>>> 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 > >