[Intel-gfx] [PATCH v2 5/9] vfio/mdev: Consolidate all the device_api sysfs into the core code
Alex Williamson
alex.williamson at redhat.com
Fri Sep 10 16:09:51 UTC 2021
On Fri, 10 Sep 2021 10:38:50 -0300
Jason Gunthorpe <jgg at nvidia.com> wrote:
> On Fri, Sep 10, 2021 at 01:10:46PM +0100, Christoph Hellwig wrote:
> > On Thu, Sep 09, 2021 at 04:38:45PM -0300, Jason Gunthorpe wrote:
> > > Every driver just emits a static string, simply feed it through the ops
> > > and provide a standard sysfs show function.
> >
> > Looks sensible. But can you make the attribute optional and add a
> > comment marking it deprecated? Because it really is completely useless.
> > We don't version userspace APIs, userspae has to discover new features
> > individually by e.g. finding new sysfs files or just trying new ioctls.
>
> To be honest I have no idea what side effects that would have..
>
> device code search tells me libvirt reads it and stuffs it into some
> XML
>
> Something called mdevctl touches it, feeds it into some JSON and
> other stuff..
>
> qemu has some VFIO_DEVICE_API_* constants but it is all dead code
>
> I agree it shouldn't have been there in the first place
>
> Cornelia? Alex? Any thoughts?
It's not a version, it's a means for userspace to determine the basic
API for an mdev device without needing to go through the process of
creating a container, adding the group, setting an IOMMU type, opening
the device before being able to call VFIO_DEVICE_GET_INFO to determine
the API. For example, it wouldn't make sense for libvirt to attach a
vfio-ccw device to a PCIe root port in a VM. It's a means to say this
mdev device is a vfio-pci or that mdev device is a vfio-ccw. If it were
optional, then management tools would have no basic idea how to attach
the device to a VM without gaining access to the device themselves.
Thanks,
Alex
More information about the Intel-gfx
mailing list