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

[Neo Jia]

On Wed, Feb 17, 2016 at 07:51:12AM +0000, Tian, Kevin wrote:
> > From: Neo Jia [mailto:address@hidden
> > Sent: Wednesday, February 17, 2016 3:32 PM
> > 
> > On Wed, Feb 17, 2016 at 07:52:53AM +0100, Gerd Hoffmann wrote:
> > >   Hi,
> > >
> > > > The answer is simple, having a UUID as part of the device name will 
> > > > give you a
> > > > unique sysfs path that will be opened by QEMU.
> > >
> > > A descriptive name will work too, and I think it'll be easier to make
> > > those names persistent because you don't have to store the uuids
> > > somewhere to re-create the same setup afer reboot.
> > 
> > Hi Gerd,
> > 
> > Right, UUID will be persistent cross reboot. The qemu vgpu path for a given 
> > VM will
> > not get changed when it gets reboots and multiple other devices have been
> > created in the middle.
> 
> Curious why persistence matters here. It's completely OK to assign 
> another vgpu to this VM across reboot, as long as the new vgpu
> provides same capability to previous one.

Hi Kevin,

Those virtual devices might be destroyed and re-created as part of the reboot or
shutdown. The user doesn't want to change his configuration, if the
path is not associated with UUID, the user might get a different vgpu than his
previous configuration, unpredictable.

We can't change the vgpu configuration behind uses back, especially we have a
lot of physical devices and tons virtual gpus can be assigned.

Also, if user wants to move the vm configuration to a different host, it is more
nature to decouple the vgpu configuration from VM itself. So the VM will only
open up the device addressed by the corresponding UUID, what you need is just to
describe his vgpu, and it doesn't matter how you describe and doesn't matter
how many virtual devices have been created already on that physical device, your
QEMU path is always persistent.

Thanks,
Neo

> 
> Thanks
> Kevin