[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v7 2/3] VFIO: Helper function to retrieve contai

From: Alex Williamson
Subject: Re: [Qemu-devel] [PATCH v7 2/3] VFIO: Helper function to retrieve container fd
Date: Tue, 27 May 2014 15:32:22 -0600

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]