[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration
From: |
Alex Williamson |
Subject: |
Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration |
Date: |
Tue, 20 Sep 2016 22:36:35 -0600 |
On Wed, 21 Sep 2016 03:56:21 +0000
"Tian, Kevin" <address@hidden> wrote:
> > From: Kirti Wankhede [mailto:address@hidden
> > 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
- Re: [Qemu-devel] [libvirt] [RFC v2] libvirt vGPU QEMU integration, (continued)
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Kirti Wankhede, 2016/09/29
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Tian, Kevin, 2016/09/21
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Alex Williamson, 2016/09/21
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Tian, Kevin, 2016/09/21
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Tian, Kevin, 2016/09/22
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Kirti Wankhede, 2016/09/23
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Tian, Kevin, 2016/09/20
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration,
Alex Williamson <=
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Tian, Kevin, 2016/09/21
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Alex Williamson, 2016/09/21
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Tian, Kevin, 2016/09/21
- Message not available
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Tian, Kevin, 2016/09/21
Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Tian, Kevin, 2016/09/19
Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Daniel P. Berrange, 2016/09/20