Messages in this thread | | | Date | Fri, 20 Nov 2015 10:46:54 +0800 | From | Jike Song <> | Subject | Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel |
| |
On 11/19/2015 07:09 PM, Paolo Bonzini wrote: > On 19/11/2015 09:40, Gerd Hoffmann wrote: >>>> But this code should be >>>> minor to be maintained in libvirt. >> As far I know libvirt only needs to discover those devices. If they >> look like sr/iov devices in sysfs this might work without any changes to >> libvirt. > > I don't think they will look like SR/IOV devices. > > The interface may look a little like the sysfs interface that GVT-g is > already using. However, it should at least be extended to support > multiple vGPUs in a single VM. This might not be possible for Intel > integrated graphics, but it should definitely be possible for discrete > graphics cards.
Didn't hear about multiple vGPUs for a single VM before. Yes If we expect same vGPU interfaces for different vendors, abstraction and vendor specific stuff should be implemented.
> Another nit is that the VM id should probably be replaced by a UUID > (because it's too easy to stumble on an existing VM id), assuming a VM > id is needed at all.
For the last assumption, yes, a VM id is not necessary for gvt-g, it's only a temporary implementation.
As long as libvirt is used, UUID should be enough for gvt-g. However, UUID is not mandatory? What should we do if user don't specify an UUID in QEMU cmdline?
> > Paolo >
-- Thanks, Jike
| |