On Wed, 2014-05-28 at 06:36 +1000, Benjamin Herrenschmidt wrote: > On Tue, 2014-05-27 at 12:27 -0600, Alex Williamson wrote: > > > Ugh, the patches are flying too fast, I can't even keep track that this > > is a QEMU patch. I'm not as concerned about the "get" in QEMU, but do > > we really want to create a future hotplug issue where we've handed out a > > file descriptor to another part of QEMU without a path to disable it > > when it gets closed? I really have no idea what else you're relying on > > being exported here since we're building patches on top of out-of-tree > > patches. > > Out-of-tree, you mean the powerpc VFIO bits ? The stuff that still > hasn't been merged almost a year after first submission ? :-)
I review it every time it gets posted. It doesn't seem like everything in that tree has been posted yet though. > In any case, if you look at Gavin's next patch which uses this exported > fd you'll see that it's never kept along. It's purely a sequence of > RTAS handlers that do: > > get fd > do ioctl > return to guest > > Ie, they are short lived and this code is intimately linked to spapr > PCI so it will have to handle hotplug as well (hotplug for us goes > via RTAS calls too). I think there shouldn't be a problem. > > Now, we can move those into a pile of additional wrappers and call them > vfio-eeh.c but it's a bit pointless isn't it ? We could also make a single wrapper int vfio_pci_container_ioctl(int iommu_group_id, int request, ...); I think that would make it's usage harder to get wrong than exposing a data element and trusting the consumer not to use it incorrectly. Thanks, Alex
