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

[Alexander Graf]

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

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


Alex