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