From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: iommu=dom0-passthrough behavior Date: Tue, 13 Nov 2012 11:24:44 +0000 Message-ID: <50A23C0C02000078000A8085@nat28.tlf.novell.com> References: <5097DB9102000078000A65C7@nat28.tlf.novell.com> <50A20DE302000078000A7F6B@nat28.tlf.novell.com> <50A223DE02000078000A7FE6@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Xiantao Zhang , Yang Z Zhang Cc: "wei.huang2@amd.com" , "weiwang.dd@gmail.com" , xen-devel List-Id: xen-devel@lists.xenproject.org >>> On 13.11.12 at 12:13, "Zhang, Yang Z" wrote: > Jan Beulich wrote on 2012-11-13: >>>>> On 13.11.12 at 09:50, "Zhang, Xiantao" wrote: >>>> From: Jan Beulich [mailto:JBeulich@suse.com] >>>> Bottom line - I'm seeking advice as to whether working around this problem >>>> in the IOMMU code is desirable/necessary, or whether this is a design flaw >>>> on the device's side that just cannot be tolerated with an IOMMU in the >>>> picture (which would need good reasoning, so that a customer expecting >>>> such a device to work regardless of IOMMU usage can understand that this >>>> cannot reasonably be made work). > > Why not just disable the IOMMU in this case ? Because that disables (secure) pass through of other devices. >>> The issue is why the non-zero functions don't claim themselves during PCI bus >>> scan. >> >> As said - I can't tell whether there is a secondary function in the >> first place (and I didn't try to find out because it doesn't really >> matter for the purpose of finding a solution/workaround). > > If software cannot see it, then how to use it? If there still have an > approach to detect it, then xen can do it too and setup the context entry as > passthrough. We see it the latest at the point the fault occurs. So there are multiple options: a) if the device is "real" as in having a valid config space despite func 0 not advertising itself as multi-function, we have ways to discover the device (at boot time) b) we could insert the context entry in the fault handler, assuming the device is able to recover c) we could provide a command line option to allow fake devices to be created d) we could create context entries for all BDFs, whether or not a device exists there Does any of these have obvious downsides? Jan