[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] iommu=dom0-passthrough behavior

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Tuesday, November 13, 2012 11:29 PM
> To: Zhang, Xiantao; Zhang, Yang Z
> Cc: wei.huang2@xxxxxxx; weiwang.dd@xxxxxxxxx; xen-devel
> Subject: RE: [Xen-devel] iommu=dom0-passthrough behavior
> >>> On 13.11.12 at 16:02, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
> wrote:
> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> > 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. 

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.