Re: iommu=dom0-passthrough behavior

["Zhang, Xiantao" <xiantao.zhang@intel.com>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Tuesday, November 13, 2012 7:25 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 12:13, "Zhang, Yang Z" <yang.z.zhang@intel.com> wrote:
> > Jan Beulich wrote on 2012-11-13:
> >>>>> On 13.11.12 at 09:50, "Zhang, Xiantao" <xiantao.zhang@intel.com>
> 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)

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


> 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. 

> 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. 

> Does any of these have obvious downsides?
> 
> Jan