[libvirt] [RFC v2] libvirt vGPU QEMU integration

[Alex Williamson]

On Wed, 21 Sep 2016 03:56:21 +0000
"Tian, Kevin" <kevin.tian at intel.com> wrote:

> > From: Kirti Wankhede [mailto:kwankhede at nvidia.com]
> > Sent: Tuesday, September 20, 2016 10:22 PM  
> > >>
> > >> 'max_instance':
> > >>     Read-Only file. Mandatory.
> > >>     Returns integer.  Returns maximum mdev device could be created
> > >> at the moment when this file is read. This count would be updated by
> > >> vendor driver. Before creating mdev device of this type, check if
> > >> max_instance is > 0.  
> > >
> > > Didn't we discuss this being being something like "available_instances"
> > > with a "devices" sub-directory linking current devices of that type?
> > >  
> > 
> > I'm ok with 'available_instances' as name of this file.
> > Yes, mdev device directory will have links to devices of that type. I
> > think that is part of mdev core module discussion. I'm trying to list
> > sysfs files for libvirt interface here to focus more on libvirt
> > interface. Hence didn't add that. I'll make sure to add all such details
> > in future.
> > 
> >   
> 
> Definitely you need provide those details since they also contain
> libvirt interface, e.g. 'destroy' which we discussed should be in
> mdev directory.

$ find /sys/devices -name remove | wc -l
24
$ find /sys/devices -name destroy | wc -l
0

'remove' is the sysfs deconstructor we should use.

> Another example is class-specific attributes such
> as 'resolution', etc. which you listed under 'display class'. All those
> attributes should be moved to mdev directory. Only class ID is
> required under each type.

Can you elaborate on what you're proposing here?  If we don't have
attributes like 'resolution' under the type-id then we can't describe
to the user the features of the mdev before we create it.  I don't
think anybody wants a 'create it and find out' type of interface.
Thanks,

Alex