qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH v1 1/1] vGPU core driver : to provide common


From: Tian, Kevin
Subject: Re: [Qemu-devel] [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU.
Date: Wed, 17 Feb 2016 08:57:08 +0000

> From: Neo Jia [mailto:address@hidden
> Sent: Wednesday, February 17, 2016 3:55 PM
> 
> On Wed, Feb 17, 2016 at 07:46:15AM +0000, Tian, Kevin wrote:
> > > From: Neo Jia
> > > Sent: Wednesday, February 17, 2016 3:26 PM
> > >
> > >
> >
> > >
> > > If your most concern is having this kind of path doesn't provide enough
> > > information of the virtual device, we can add more sysfs attributes 
> > > within the
> > > directory of /sys/devices/virtual/vgpu/$UUID-$vgpu_idx/ to reflect the
> > > information you want.
> >
> > Like Gerd said, you can have something like this:
> >
> > -device vfio-pci,sysfsdev=/sys/devices/virtual/vgpu/vgpu_idx/UUID
> 
> Hi Kevin,
> 
> The vgpu_idx is not unique number at all.
> 
> For example, how to locate the path of a given VM? Whoever is going to 
> configure
> the qemu has to walk through *all* the current vgpu path to locate the UUID to
> match the QEMU's VM UUID. This is not required if you have UUID as part of the
> device path.

'whoever' is too strict here. I don't think UUID is required in all scenarios.

In your scenario:

- You will pass VM UUID when creating a vgpu.
- Consequently a /sys/device/virtual/vgpu/$UUID-$vgpu-id is created
- Then you can identify $UUID-$vgpu-id is right for the very VM, by matching 
all available vgpu nodes with VM UUID;

When it is a bit convenient, I don't see it significant. Looping directory is
not unusual for file/directory operations and it happens infrequently only
for vgpu life-cycle mgmt..

Please think about my original proposal carefully. I'm not opposing encoding
UUID in vgpu name. What I'm opposing is not to make it mandatory, i.e. when
UUID is not provided, we should still allow vgpu creation using some default
descriptive string.

> 
> >
> > >
> > > Even with UUID, you don't need libvirt at all. you can get uuid by running
> > > uuidgen command, I don't need libvirt to code up and test the RFC that I 
> > > have
> > > sent out early. :-)
> >
> > although simple, it still creates unnecessary user space dependency for
> > kernel resource management...
> 
> I think I has answered this, UUID is not a user space or kernel space
> concept, it is just a generic way to represent object, it just make sure that
> virtual gpu device directory can be uniquely addressed.
> 

'user space dependency' means you need additional user-space operations
(say uuidgen here) before you can utilize GPU virtualization feature, which
is not necessary. In reality, UUID is not a GPU resource. It's not what GPU 
virtualization intrinsically needs to handle. Let's keep vGPU-core sub-system
modulo for its real functionalities.

So let's keep UUID as an optional parameter. When UUID is provided, it
will be included in the vGPU name then your requirement can be met.

Thanks
Kevin



reply via email to

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