From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49373) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aR3AY-0004gJ-7q for qemu-devel@nongnu.org; Wed, 03 Feb 2016 14:32:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aR3AU-0000Tu-6l for qemu-devel@nongnu.org; Wed, 03 Feb 2016 14:32:50 -0500 Received: from mx1.redhat.com ([209.132.183.28]:52836) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aR3AT-0000Tq-Vt for qemu-devel@nongnu.org; Wed, 03 Feb 2016 14:32:46 -0500 Message-ID: <1454527963.18969.8.camel@redhat.com> From: Alex Williamson Date: Wed, 03 Feb 2016 12:32:43 -0700 In-Reply-To: <1454488111.4967.39.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> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann , "Tian, Kevin" Cc: "Ruan, Shuai" , "Song, Jike" , Neo Jia , "kvm@vger.kernel.org" , qemu-devel , Kirti Wankhede , "Lv, Zhiyuan" , Paolo Bonzini 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 u= se UUID to > > mark a VM. And obviously UUID is not recorded within KVM. Then how do= es > > libvirt talk to KVM based on UUID? It could be a good reference to th= is 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 also= in the > smbios tables so the guest can see it in the system information table. >=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=A0qemu = uses file > handles to talk to both kvm and vfio.=C2=A0=C2=A0qemu notifies both kvm= 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 udev 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 associate = that userspace process with a VM instance.=C2=A0=C2=A0Maybe it could register = 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 uuid = if you want > have it that way, but it could be pretty much anything.=C2=A0=C2=A0The = 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 using = 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 cannot 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=A0That= 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 create= d 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 case that NVIDIA is trying to achieve.=C2=A0=C2=A0Thanks, Alex