[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration
From: |
Tian, Kevin |
Subject: |
Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration |
Date: |
Thu, 22 Sep 2016 02:59:56 +0000 |
> From: Tian, Kevin
> Sent: Thursday, September 22, 2016 10:33 AM
>
> >
> > > 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,
> >
>
> I think such way would be racy. What about two clients creating mdev
> devices simultaneously? How to guarantee their configuration of class
> specific attributes not mutual-impacted since before creation any such
> configuration would be global under that type?
>
> My feeling is that we'd better keep create simple - just write a UUID
> to "type-id/create". Any class-specific attribute, if we really want to
> support, should be able to be individually configured with required
> resource allocated incrementally on top of basic resources allocated
> at create stage. Then libvirt can set those attributes between create
> and open a mdev device. If this direction is accepted, then naturally
> such attributes should be put under mdev directory. Possibly we
> don't need a class description under type-id. libvirt just checks directly
> whether any known class represented in each mdev directory (vendor
> driver will expose it on demand), and then operate attributes under
> that class.
>
Have a better understanding of your concern now. User needs to know
and set a list of attributes before requesting to create a new mdev
device. From this angle all attributes should be enumerated per type-id.
But as I explained above, writing multiple sysfs nodes to create a
mdev device is racy. We either need a way to guarantee transactional
operations on those nodes, or having type-id directory to only expose
supported attributes while programming those attributes has to be
through per-mdev directory after mdev device is created...
Thanks
Kevin
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, (continued)
- 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, 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, 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 <=
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
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Neo Jia, 2016/09/28
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Daniel P. Berrange, 2016/09/29
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Tian, Kevin, 2016/09/29
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Daniel P. Berrange, 2016/09/29
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Tian, Kevin, 2016/09/29
- Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration, Kirti Wankhede, 2016/09/30