On 01/26/2016 05:30 AM, Alex Williamson wrote:
[cc +Neo @Nvidia]
Hi Jike,
On Mon, 2016-01-25 at 19:34 +0800, Jike Song wrote:
On 01/20/2016 05:05 PM, Tian, Kevin wrote:
I would expect we can spell out next level tasks toward above
direction, upon which Alex can easily judge whether there are
some common VFIO framework changes that he can help :-)
Hi Alex,
Here is a draft task list after a short discussion w/ Kevin,
would you please have a look?
Bus Driver
{ in i915/vgt/xxx.c }
- define a subset of vfio_pci interfaces
- selective pass-through (say aperture)
- trap MMIO: interface w/ QEMU
What's included in the subset? Certainly the bus reset ioctls really
don't apply, but you'll need to support the full device interface,
right? That includes the region info ioctl and access through the vfio
device file descriptor as well as the interrupt info and setup ioctls.
[All interfaces I thought are via ioctl:) For other stuff like file
descriptor we'll definitely keep it.]
The list of ioctl commands provided by vfio_pci:
- VFIO_DEVICE_GET_PCI_HOT_RESET_INFO
- VFIO_DEVICE_PCI_HOT_RESET
As you said, above 2 don't apply. But for this:
- VFIO_DEVICE_RESET
In my opinion it should be kept, no matter what will be provided in
the bus driver.
- VFIO_PCI_ROM_REGION_INDEX
- VFIO_PCI_VGA_REGION_INDEX
I suppose above 2 don't apply neither? For a vgpu we don't provide a
ROM BAR or VGA region.
- VFIO_DEVICE_GET_INFO
- VFIO_DEVICE_GET_REGION_INFO
- VFIO_DEVICE_GET_IRQ_INFO
- VFIO_DEVICE_SET_IRQS
Above 4 are needed of course.
We will need to extend:
- VFIO_DEVICE_GET_REGION_INFO
a) adding a flag: DONT_MAP. For example, the MMIO of vgpu
should be trapped instead of being mmap-ed.
b) adding other information. For example, for the OpRegion, QEMU need
to do more than mmap a region, it has to:
- allocate a region
- copy contents from somewhere in host to that region
- mmap it to guest
I remember you already have a prototype for this?
IOMMU
{ in a new vfio_xxx.c }
- allocate: struct device & IOMMU group
It seems like the vgpu instance management would do this.
Yes, it can be removed from here.
- map/unmap functions for vgpu
- rb-tree to maintain iova/hpa mappings
Yep, pretty much what type1 does now, but without mapping through the
IOMMU API. Essentially just a database of the current userspace
mappings that can be accessed for page pinning and IOVA->HPA
translation.
Yes.
- interacts with kvmgt.c
vgpu instance management
{ in i915 }
- path, create/destroy
Yes, and since you're creating and destroying the vgpu here, this is
where I'd expect a struct device to be created and added to an IOMMU
group. The lifecycle management should really include links between
the vGPU and physical GPU, which would be much, much easier to do with
struct devices create here rather than at the point where we start
doing vfio "stuff".
Yes, just like the SRIOV does.
Nvidia has also been looking at this and has some ideas how we might
standardize on some of the interfaces and create a vgpu framework to
help share code between vendors and hopefully make a more consistent
userspace interface for libvirt as well. I'll let Neo provide some
details. Thanks,
Good to know that, so we can possibly cooperate on some common part,
e.g. the instance management :)
Alex
--
Thanks,
Jike
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to address@hidden
More majordomo info at http://vger.kernel.org/majordomo-info.html