From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Wang Subject: Re: [PATCH] amd iommu: re-enable iommu msi if dom0 disabled it Date: Fri, 8 Jun 2012 16:16:11 +0200 Message-ID: <4FD2092B.3030209@amd.com> References: <4FD1FDE2.5010907@amd.com> <4FD1FEC8.5000708@citrix.com> <4FD200EC.6050005@amd.com> <4FD223710200007800088CC3@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: <4FD223710200007800088CC3@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 , "xen-devel@lists.xensource.com" , "Keir (Xen.org)" List-Id: xen-devel@lists.xenproject.org On 06/08/2012 04:08 PM, Jan Beulich wrote: >>>> On 08.06.12 at 15:41, Wei Wang wrote: >> On 06/08/2012 03:31 PM, Andrew Cooper wrote: >>> On 08/06/12 14:28, Wei Wang wrote: >>>> I found that recent dom0 (e.g 3.4 pv_ops) disables iommu msi capability >>>> for some reasons and iommu cannot generate any interrupts in this case. >>>> Attached patch re-enables it in device assignment. >>> >>> Under which circumstances should dom0 able to play with the IOMMUs ? >>> Surely the fact that dom0 can play with the IOMMUs is a bug in itself. >> >> It looks like some generic msi/pci codes disable it, not the Linux iommu >> driver itself, which is only loaded on bare metal. AMD IOMMU expose >> interrupt capability as a normal msi block. So the general pci/msi layer >> of dom0 might touch it... > > In that case it wouldn't be on pv-ops alone (which your patch > says). Yes, probably upstream Linux also has this issue. I will check that. But I did not see this issue on 3.2 pv_ops & 2.6 pv_ops. > Also, your patch using IOMMU_CONTROL_ENABLED instead of > PCI_MSI_FLAGS_ENABLE is quite misleading (as it hides the fact > the what you play with is not IOMMU-specific). Thanks, I will use PCI_MSI_FLAGS_ENABLE in next post. Wei > Jan > >