Re: [Qemu-devel] vfio for platform devices - 9/5/2012 - minutes

[Scott Wood]

On Thu, 2013-09-12 at 16:48 -0500, Alexander Graf wrote:
> On 12.09.2013, at 16:45, Scott Wood wrote:
> 
> > On Thu, 2013-09-12 at 16:23 -0500, Alexander Graf wrote:
> >> On 12.09.2013, at 13:10, Scott Wood wrote:
> >> 
> >>> On Thu, 2013-09-12 at 04:18 -0500, Bhushan Bharat-R65777 wrote:
> >>>> and device disabling is not a standard like PCI. Do you think that we 
> >>>> might need to do some
> >>>> device specific handling.
> >>> 
> >>> It would be better if we could avoid the need for device specific
> >>> handling.  DMA can be disabled via the IOMMU.
> >>> 
> >>> The tricky part is how to enable the device in the next user; as I wrote
> >>> elsewhere in the thread I think this needs to be something the user is
> >>> aware of, so that the user quiesces the device prior to enabling IOMMU
> >>> mappings.
> >> 
> >> Or resets it. I think we can make it mandatory to VFIO users (and Linux
> >> drivers) to reset the device prior to mapping it.
> > 
> > Reset is one way to quiesce it, but as Bharat pointed out not all
> > devices make that possible (even with device specific knowledge).  In
> > particular, Freescale datapath stuff has problems with this.
> 
> I'm sure once Freescale datapath drivers are upstream in Linux we can also 
> get that code upstream in QEMU :).

Yeah, but the fewer places it lives, the better. :-)

> >> QEMU needs to have device specific code to assemble its device tree 
> >> fragment anyways, so
> >> it can just as well reset the device before it enables it to DMA.
> > 
> > Now you're adding to the depth of knowledge QEMU needs to have about a
> > device.  It's not that big of a deal if it's just "set this bit and wait
> > for it to clear", but it could be a pain with a device that can't be
> > reset and has a complicated sequence needed to quiesce -- and as you
> > noted above, Linux drivers would need to take care of this anyway.
> > Doing it in QEMU would still help with non-Linux guests and avoid the
> > need for a hypercall to indicate when the IOMMU can be opened, though.
> 
> Yes, and you don't want to burden the Linux driver with a situation it 
> doesn't face in non-virtualized environments :).

The driver does need to handle it in non-virtualized environments, if
you want to be able to return a device to the host driver after a VFIO
user has had it.  It will also be needed for kexec.

-Scott