From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Zhang, Xiantao" Subject: Re: iommu=dom0-passthrough behavior Date: Wed, 14 Nov 2012 00:37:39 +0000 Message-ID: References: <5097DB9102000078000A65C7@nat28.tlf.novell.com> <50A20DE302000078000A7F6B@nat28.tlf.novell.com> <50A223DE02000078000A7FE6@nat28.tlf.novell.com> <50A23C0C02000078000A8085@nat28.tlf.novell.com> <50A2755402000078000A837D@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <50A2755402000078000A837D@nat28.tlf.novell.com> Content-Language: en-US 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 , "Zhang, Yang Z" Cc: "wei.huang2@amd.com" , "weiwang.dd@gmail.com" , "Zhang, Xiantao" , xen-devel List-Id: xen-devel@lists.xenproject.org > -----Original Message----- > From: Jan Beulich [mailto:JBeulich@suse.com] > Sent: Tuesday, November 13, 2012 11:29 PM > To: Zhang, Xiantao; Zhang, Yang Z > Cc: wei.huang2@amd.com; weiwang.dd@gmail.com; xen-devel > Subject: RE: [Xen-devel] iommu=dom0-passthrough behavior > > >>> On 13.11.12 at 16:02, "Zhang, Xiantao" > wrote: > >> From: Jan Beulich [mailto:JBeulich@suse.com] > >> > 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) > > > > I think current Xen logic also covers multi-function devices case. > > When Xen boots up, it will scan all functions of devices on each bus, > > through reads their vendor ID. If the vendor ID is valid, Xen deems > > this BDF has a real device/function existed there > > Not anymore - we're now honoring the multi-function flag in > _scan_pci_devices() (as Linux always did in its bus scan logic); see c/s > 22337:7afd8dd1d6cb (with a subsequent adjustment in c/s > 25869:59b3663316db). > > >> b) we could insert the context entry in the fault handler, assuming > >> the device is able to recover > > At least current VT-d doesn't have recovery fault supported, so each > > triggered faults are fatal. > > Fatal in what sense? I would assume that if the driver retries the operation, it > would succeed if the first fault causes the context entry to be inserted. If the driver knows the fact, it should work. For VT-d without fault recovery capability, it should do nothing for the unknown translations which maybe faked by some malicious devices. > >> c) we could provide a command line option to allow fake devices to > >> be create > > > > Agree, this maybe a feasible solution I can figure out, so far. > > > >> d) we could create context entries for all BDFs, whether or not a > >> device exists there > > > > As I said, this maybe bring security issue. Even for the > > iommu-passthrough option, it is also not suggested to be used if security is > considered. > > As said - it is clear that the basic thing here (using > "iommu=dom0-passthrough") is already weakening security. So security isn't > the concern in this discussion, that's left to whoever is intending to use that > option. Okay, I vote your option C if don't care security. Xiantao