qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH] vfio: Add sysfsdev property for pci & platf


From: Tian, Kevin
Subject: Re: [Qemu-devel] [RFC PATCH] vfio: Add sysfsdev property for pci & platform
Date: Mon, 25 Jan 2016 19:27:40 +0000

> From: Alex Williamson [mailto:address@hidden
> Sent: Thursday, January 21, 2016 11:15 PM
> 
> On Thu, 2016-01-21 at 07:51 +0000, Tian, Kevin wrote:
> > > From: Alex Williamson [mailto:address@hidden
> > > Sent: Thursday, January 21, 2016 2:07 AM
> > >
> > > vfio-pci currently requires a host= parameter, which comes in the
> > > form of a PCI address in [domain:] notation.  We
> > > expect to find a matching entry in sysfs for that under
> > > /sys/bus/pci/devices/.  vfio-platform takes a similar approach, but
> > > defines the host= parameter to be a string, which can be matched
> > > directly under /sys/bus/platform/devices/.  On the PCI side, we have
> > > some interest in using vfio to expose vGPU devices.  These 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.  There'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.  To fit within the vfio framework, it
> > > would need a kernel struct device and associated IOMMU group, but
> > > those are easy constraints to manage.
> > >
> > > 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.  The
> > > vfio API already has support for probing the device type to ensure
> > > compatibility with either vfio-pci or vfio-platform.
> > >
> > > With this, a vfio-pci device could either be specified as:
> > >
> > > -device vfio-pci,host=02:00.0
> > >
> > > or
> > >
> > > -device 
> > > vfio-pci,sysfsdev=/sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0
> > >
> > > or even
> > >
> > > -device vfio-pci,sysfsdev=/sys/bus/pci/devices/0000:02:00.0
> > >
> > > When vGPU support comes along, this might look something more like:
> > >
> > > -device 
> > > vfio-pci,sysfsdev=/sys/devices/virtual/intel-vgpu/address@hidden:00:02.0
> > >
> > > 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 to
> > > conflict, such as a simple instance number.
> > >
> >
> > 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, then
> > 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.  I expect that vGPUs will create singleton groups, so the
> namespace constraints I mention above are maybe not a concern.  For
> 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.  Thanks,
> 

Agree. It's clear now.

Thanks
Kevin

reply via email to

[Prev in Thread] Current Thread [Next in Thread]