From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: iommu=dom0-passthrough behavior Date: Tue, 13 Nov 2012 09:41:34 +0000 Message-ID: <50A223DE02000078000A7FE6@nat28.tlf.novell.com> References: <5097DB9102000078000A65C7@nat28.tlf.novell.com> <50A20DE302000078000A7F6B@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 09:50, "Zhang, Xiantao" wrote: >> From: Jan Beulich [mailto:JBeulich@suse.com] >> We need to settle on the concept here first: What specifically is said >> option intended to do? > > Basically, this options just allows the transactions from dom0's devices > not subject to VT-d engine. Actually, It is not targeted to fix something, > but just allows users isolating VT-d issues from dom0. > As I know, in early days, VT-d is not that stable, if dom0's devices are > controlled by VT-d, some strange issues may trigger in system's boot stage, > so use this options to disable VT-d for Dom0. Which it doesn't, as the specific case here shows. >> 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). > > 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). > From security point of view, VT-d shouldn't allow transactions from > the unknown devices. That's inconsistent with what you say above: Either there is a way to suppress IOMMU involvement in Dom0 operation (which is inherently insecure), or there is not. If there is, there's no point in claiming security for one aspect but not another. I think it is obvious that I'm not suggesting to allow pass through of such a device at this point (albeit even that would seem possible and, from a customer's pov, desirable), and as long as users are aware of the security implications when using the option under discussion here, I don't see why that option shouldn't be made fully work. It should be left to the admins of individual systems to decide between security and functionality, we should provide them with ways to implement their choice. Otoh I'm unaware of a similar option for native Linux, yet it is suffering the same problem on that system when DMA translation gets turned on. But the direction you give to the discussion doesn't lead us towards a solution for the customer (or a profound explanation why none is possible), so if we could please focus on that aspect again. Jan