From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51319) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMGwu-0004iM-CC for qemu-devel@nongnu.org; Thu, 21 Jan 2016 10:15:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aMGwp-0007tU-90 for qemu-devel@nongnu.org; Thu, 21 Jan 2016 10:15:00 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53264) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMGwp-0007tO-1X for qemu-devel@nongnu.org; Thu, 21 Jan 2016 10:14:55 -0500 Message-ID: <1453389294.32741.360.camel@redhat.com> From: Alex Williamson Date: Thu, 21 Jan 2016 08:14:54 -0700 In-Reply-To: References: <20160120180552.21926.99964.stgit@gimli.home> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH] vfio: Add sysfsdev property for pci & platform List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Tian, Kevin" , "qemu-devel@nongnu.org" Cc: "Song, Jike" , "laine@redhat.com" , "eric.auger@linaro.org" On Thu, 2016-01-21 at 07:51 +0000, Tian, Kevin wrote: > > From: Alex Williamson [mailto:alex.williamson@redhat.com] > > Sent: Thursday, January 21, 2016 2:07 AM > >=20 > > vfio-pci currently requires a host=3D parameter, which comes in the > > form of a PCI address in [domain:] notation.=C2=A0=C2=A0We > > expect to find a matching entry in sysfs for that under > > /sys/bus/pci/devices/.=C2=A0=C2=A0vfio-platform takes a similar appro= ach, but > > defines the host=3D parameter to be a string, which can be matched > > directly under /sys/bus/platform/devices/.=C2=A0=C2=A0On the PCI side= , we have > > some interest in using vfio to expose vGPU devices.=C2=A0=C2=A0These = are not > > actual discrete PCI devices, so they don't have a compatible host PCI > > bus address or a device link where QEMU wants to look for it.=C2=A0=C2= =A0There's > > also really no requirement that vfio can only be used to expose > > physical devices, a new vfio bus and iommu driver could expose a > > completely emulated device.=C2=A0=C2=A0To fit within the vfio framewo= rk, it > > would need a kernel struct device and associated IOMMU group, but > > those are easy constraints to manage. > >=20 > > To support such devices, which would include vGPUs, that honor the > > VFIO PCI programming API, but are not necessarily backed by a unique > > PCI address, add support for specifying any device in sysfs.=C2=A0=C2= =A0The > > vfio API already has support for probing the device type to ensure > > compatibility with either vfio-pci or vfio-platform. > >=20 > > With this, a vfio-pci device could either be specified as: > >=20 > > -device vfio-pci,host=3D02:00.0 > >=20 > > or > >=20 > > -device vfio-pci,sysfsdev=3D/sys/devices/pci0000:00/0000:00:1c.0/0000= :02:00.0 > >=20 > > or even > >=20 > > -device vfio-pci,sysfsdev=3D/sys/bus/pci/devices/0000:02:00.0 > >=20 > > When vGPU support comes along, this might look something more like: > >=20 > > -device vfio-pci,sysfsdev=3D/sys/devices/virtual/intel-vgpu/vgpu0@000= 0:00:02.0 > >=20 > > NB - This is only a made up example path, but it should be noted that > > the device namespace is global for vfio, a virtual device cannot > > overlap with existing namespaces and should not create a name prone t= o > > conflict, such as a simple instance number. > >=20 >=20 > Thanks Alex! It's a good improvement to support coming vgpu feature. > Just curious. Does the virtual device name has to include a BDF format > or it can be random strings (e.g. just "vgpu0")? In the latter case, th= en > overlapping chance would be small. Hi Kevin, Yeah, looking at the vfio code again (vfio_device_get_from_name), as long as the name is unique within the IOMMU group, I think we'll be fine. =C2=A0I expect that vGPUs will create singleton groups, so the namespace constraints I mention above are maybe not a concern. =C2=A0For vendors that can support multiple GPUs, each with vGPUs, userspace will probably want some way to determine the source of a vGPU for load balancing and locality purpose, but that's better handled through parent/child device links in sysfs rather than embedding it in the device name. =C2=A0Thanks, Alex