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 -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
