From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neo Jia Subject: Re: [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU. Date: Mon, 15 Feb 2016 23:13:04 -0800 Message-ID: <20160216071304.GA6867@nvidia.com> References: <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> <1454527963.18969.8.camel@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Alex Williamson , Gerd Hoffmann , Kirti Wankhede , Paolo Bonzini , "Ruan, Shuai" , "Song, Jike" , "Lv, Zhiyuan" , "kvm@vger.kernel.org" , qemu-devel To: "Tian, Kevin" Return-path: Received: from hqemgate14.nvidia.com ([216.228.121.143]:9591 "EHLO hqemgate14.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753675AbcBPHNK convert rfc822-to-8bit (ORCPT ); Tue, 16 Feb 2016 02:13:10 -0500 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Tue, Feb 16, 2016 at 06:49:30AM +0000, Tian, Kevin wrote: > > From: Alex Williamson [mailto:alex.williamson@redhat.com] > > Sent: Thursday, February 04, 2016 3:33 AM > >=20 > > On Wed, 2016-02-03 at 09:28 +0100, Gerd Hoffmann wrote: > > > =A0 Hi, > > > > > > > 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. > > > > > > libvirt keeps track which qemu instance belongs to which vm. > > > qemu also gets started with "-uuid ...", so one can query qemu vi= a > > > monitor ("info uuid") to figure what the uuid is.=A0=A0It is also= in the > > > smbios tables so the guest can see it in the system information t= able. > > > > > > The uuid is not visible to the kernel though, the kvm kernel driv= er > > > doesn't know what the uuid is (and neither does vfio).=A0=A0qemu = uses file > > > handles to talk to both kvm and vfio.=A0=A0qemu notifies both kvm= and vfio > > > about anything relevant events (guest address space changes etc) = and > > > connects file descriptors (eventfd -> irqfd). > >=20 > > I think the original link to using a VM UUID for the vGPU comes fro= m > > 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 i= s > > started.=A0=A0Using the VM UUID then gives them a way to associate = that > > userspace process with a VM instance.=A0=A0Maybe it could register = with > > libvirt for some sort of service provided for the VM, I don't know. >=20 > Intel doesn't have this requirement. It should be enough as long as > libvirt maintains which sysfs vgpu node is associated to a VM UUID. >=20 > >=20 > > > qemu needs a sysfs node as handle to the vfio device, something > > > like /sys/devices/virtual/vgpu/.=A0=A0 can be a uuid = if you want > > > have it that way, but it could be pretty much anything.=A0=A0The = sysfs node > > > will probably show up as-is in the libvirt xml when assign a vgpu= to a > > > vm.=A0=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). > >=20 > > Actually I don't think there's really a persistent naming issue, th= at's > > probably where we diverge from the SR-IOV model.=A0=A0SR-IOV cannot > > dynamically add a new VF, it needs to reset the number of VFs to ze= ro, > > then re-allocate all of them up to the new desired count.=A0=A0That= has some > > obvious implications.=A0=A0I think with both vendors here, we can > > dynamically allocate new vGPUs, so I would expect that libvirt woul= d > > create each vGPU instance as it's needed.=A0=A0None would be create= d by > > default without user interaction. > >=20 > > 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.=A0=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.=A0=A0Thanks, > >=20 >=20 > I would prefer to making UUID an optional parameter, while not tieing > sysfs vgpu naming to UUID. This would be more flexible to different > scenarios where UUID might not be required. Hi Kevin, Happy Chinese New Year! I think having UUID as the vgpu device name will allow us to have an gp= u vendor agnostic solution for the upper layer software stack such as QEMU, who = is supposed to open the device. Thanks, Neo >=20 > Thanks > Kevin