qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH v3 1/3] vGPU Core driver


From: Tian, Kevin
Subject: Re: [Qemu-devel] [RFC PATCH v3 1/3] vGPU Core driver
Date: Thu, 12 May 2016 08:22:56 +0000

Hi, Kirti/Neo, any response for below comment?

> From: Tian, Kevin
> Sent: Wednesday, May 04, 2016 10:59 AM
> 
> > From: Alex Williamson
> > Sent: Wednesday, May 04, 2016 6:44 AM
> > > +/**
> > > + * struct gpu_device_ops - Structure to be registered for each physical 
> > > GPU to
> > > + * register the device to vgpu module.
> > > + *
> > > + * @owner:                       The module owner.
> > > + * @dev_attr_groups:             Default attributes of the physical 
> > > device.
> > > + * @vgpu_attr_groups:            Default attributes of the vGPU device.
> > > + * @vgpu_supported_config:       Called to get information about 
> > > supported vgpu
> types.
> > > + *                               @dev : pci device structure of physical 
> > > GPU.
> > > + *                               @config: should return string listing 
> > > supported config
> > > + *                               Returns integer: success (0) or error 
> > > (< 0)
> > > + * @vgpu_create:         Called to allocate basic resouces in graphics
> 
> It's redundant to have vgpu prefixed to every op here. Same comment
> for later sysfs node.
> 
> > > + *                               driver for a particular vgpu.
> > > + *                               @dev: physical pci device structure on 
> > > which vgpu
> > > + *                                     should be created
> > > + *                               @uuid: VM's uuid for which VM it is 
> > > intended to
> > > + *                               @instance: vgpu instance in that VM
> 
> I didn't quite get @instance here. Is it whatever vendor specific format
> to indicate a vgpu?
> 
> > > + *                               @vgpu_params: extra parameters required 
> > > by GPU driver.
> > > + *                               Returns integer: success (0) or error 
> > > (< 0)
> > > + * @vgpu_destroy:                Called to free resources in graphics 
> > > driver for
> > > + *                               a vgpu instance of that VM.
> > > + *                               @dev: physical pci device structure to 
> > > which
> > > + *                               this vgpu points to.
> > > + *                               @uuid: VM's uuid for which the vgpu 
> > > belongs to.
> > > + *                               @instance: vgpu instance in that VM
> > > + *                               Returns integer: success (0) or error 
> > > (< 0)
> > > + *                               If VM is running and vgpu_destroy is 
> > > called that
> > > + *                               means the vGPU is being hotunpluged. 
> > > Return error
> > > + *                               if VM is running and graphics driver 
> > > doesn't
> > > + *                               support vgpu hotplug.
> > > + * @vgpu_start:                  Called to do initiate vGPU 
> > > initialization
> > > + *                               process in graphics driver when VM 
> > > boots before
> > > + *                               qemu starts.
> > > + *                               @uuid: VM's UUID which is booting.
> > > + *                               Returns integer: success (0) or error 
> > > (< 0)
> > > + * @vgpu_shutdown:               Called to teardown vGPU related 
> > > resources for
> > > + *                               the VM
> > > + *                               @uuid: VM's UUID which is shutting down 
> > > .
> > > + *                               Returns integer: success (0) or error 
> > > (< 0)
> 
> Can you give some specific example about difference between destroy
> and shutdown? Want to map it correctly into our side, e.g. whether we
> need implement both or just one of them.
> 
> Another optional op is 'stop', allowing physical device to stop scheduling
> vGPU including wait for in-flight DMA done. It would be useful to support
> VM live migration with vGPU assigned.
> 



reply via email to

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