From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:40676)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1aQsnm-0003cm-9r
	for qemu-devel@nongnu.org; Wed, 03 Feb 2016 03:28:39 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1aQsni-0001iU-Vh
	for qemu-devel@nongnu.org; Wed, 03 Feb 2016 03:28:38 -0500
Received: from mx1.redhat.com ([209.132.183.28]:37135)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1aQsni-0001iQ-Qs
	for qemu-devel@nongnu.org; Wed, 03 Feb 2016 03:28:34 -0500
Message-ID: <1454488111.4967.39.camel@redhat.com>
From: Gerd Hoffmann <kraxel@redhat.com>
Date: Wed, 03 Feb 2016 09:28:31 +0100
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D15F79CB04@SHSMSX103.ccr.corp.intel.com>
References: <56AFD231.3010404@nvidia.com> <56B00AD7.6070103@nvidia.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D15F7940CB@SHSMSX101.ccr.corp.intel.com>
	<1454400043.9300.31.camel@redhat.com>
	<20160202081312.GA9895@nvidia.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D15F794234@SHSMSX101.ccr.corp.intel.com>
	<20160202083114.GB9895@nvidia.com>
	<1454433079.30910.3.camel@redhat.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D15F79CB04@SHSMSX103.ccr.corp.intel.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0
Subject: Re: [Qemu-devel] [RFC PATCH v1 1/1] vGPU core driver : to provide
 common interface for vGPU.
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: "Ruan, Shuai" <shuai.ruan@intel.com>, "Song, Jike" <jike.song@intel.com>, Neo Jia <cjia@nvidia.com>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>, Kirti Wankhede <kwankhede@nvidia.com>, qemu-devel <qemu-devel@nongnu.org>, Alex Williamson <alex.williamson@redhat.com>, "Lv,
	Zhiyuan" <zhiyuan.lv@intel.com>, Paolo Bonzini <pbonzini@redhat.com>

  Hi,

> Actually I have a long puzzle in this area. Definitely libvirt will use U=
UID 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 d=
esign.

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.  It is also in the
smbios tables so the guest can see it in the system information table.

The uuid is not visible to the kernel though, the kvm kernel driver
doesn't know what the uuid is (and neither does vfio).  qemu uses file
handles to talk to both kvm and vfio.  qemu notifies both kvm and vfio
about anything relevant events (guest address space changes etc) and
connects file descriptors (eventfd -> irqfd).

qemu needs a sysfs node as handle to the vfio device, something
like /sys/devices/virtual/vgpu/<name>.  <name> can be a uuid if you want
have it that way, but it could be pretty much anything.  The sysfs node
will probably show up as-is in the libvirt xml when assign a vgpu to a
vm.  So 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).

cheers,
  Gerd