From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Williamson Subject: Re: [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU. Date: Wed, 03 Feb 2016 12:32:43 -0700 Message-ID: <1454527963.18969.8.camel@redhat.com> References: <56AFD231.3010404@nvidia.com> <56B00AD7.6070103@nvidia.com> <1454400043.9300.31.camel@redhat.com> <20160202081312.GA9895@nvidia.com> <20160202083114.GB9895@nvidia.com> <1454433079.30910.3.camel@redhat.com> <1454488111.4967.39.camel@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Neo Jia , Kirti Wankhede , Paolo Bonzini , "Ruan, Shuai" , "Song, Jike" , "Lv, Zhiyuan" , "kvm@vger.kernel.org" , qemu-devel To: Gerd Hoffmann , "Tian, Kevin" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:41756 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933040AbcBCTcp (ORCPT ); Wed, 3 Feb 2016 14:32:45 -0500 In-Reply-To: <1454488111.4967.39.camel@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, 2016-02-03 at 09:28 +0100, Gerd Hoffmann wrote: > =C2=A0 Hi, >=C2=A0 > > Actually I have a long puzzle in this area. Definitely libvirt will= use UUID to > > mark a VM. And obviously UUID is not recorded within KVM. Then how = does > > libvirt talk to KVM based on UUID? It could be a good reference to = this design. >=C2=A0 > libvirt keeps track which qemu instance belongs to which vm. > qemu also gets started with "-uuid ...", so one can query qemu via > monitor ("info uuid") to figure what the uuid is.=C2=A0=C2=A0It is al= so in the > smbios tables so the guest can see it in the system information table= =2E >=C2=A0 > The uuid is not visible to the kernel though, the kvm kernel driver > doesn't know what the uuid is (and neither does vfio).=C2=A0=C2=A0qem= u uses file > handles to talk to both kvm and vfio.=C2=A0=C2=A0qemu notifies both k= vm and vfio > about anything relevant events (guest address space changes etc) and > connects file descriptors (eventfd -> irqfd). I think the original link to using a VM UUID for the vGPU comes from NVIDIA having a userspace component which might get launched from a ude= v event as the vGPU is created or the set of vGPUs within that UUID is started.=C2=A0=C2=A0Using the VM UUID then gives them a way to associat= e that userspace process with a VM instance.=C2=A0=C2=A0Maybe it could registe= r with libvirt for some sort of service provided for the VM, I don't know. > qemu needs a sysfs node as handle to the vfio device, something > like /sys/devices/virtual/vgpu/.=C2=A0=C2=A0 can be a uui= d if you want > have it that way, but it could be pretty much anything.=C2=A0=C2=A0Th= e sysfs node > will probably show up as-is in the libvirt xml when assign a vgpu to = a > vm.=C2=A0=C2=A0So the name should be something stable (i.e. when usin= g a uuid as > name you should better not generate a new one on each boot). Actually I don't think there's really a persistent naming issue, that's probably where we diverge from the SR-IOV model.=C2=A0=C2=A0SR-IOV cann= ot dynamically add a new VF, it needs to reset the number of VFs to zero, then re-allocate all of them up to the new desired count.=C2=A0=C2=A0Th= at has some obvious implications.=C2=A0=C2=A0I think with both vendors here, we can dynamically allocate new vGPUs, so I would expect that libvirt would create each vGPU instance as it's needed.=C2=A0=C2=A0None would be crea= ted by default without user interaction. Personally I think using a UUID makes sense, but it needs to be userspace policy whether that UUID has any implicit meaning like matching the VM UUID.=C2=A0=C2=A0Having an index within a UUID bothers = me a bit, but it doesn't seem like too much of a concession to enable the use cas= e that NVIDIA is trying to achieve.=C2=A0=C2=A0Thanks, Alex