***Background context:
We are using kvm on a x86 based platform. For performance reason, we use
devices assignment. The type of devices we have to deal with is mostly
custom ASICs but we also have standard stuff (ex 82599EB 10-GigabitSR-IOV).
AER handling in guest VM is very important to us. Most of our drivers
assume timely notification in cases of PCIe AER. Failure to provide such
support will result in very undesireable behavior at the other end :)
In our cases, AER is not strictly function of the hardware 'quality' but
also tied to the way the user can interact with the system (by pulling a
card on the fly for example).
***Q35, VFIO:
I'm aware of the PCIe Q35 chipset work that Isaku is working on. I have a
college that is working actively on merging the change into our qemu-kvm branch.
I'm also familiar with VFIO. I've seen the work from Alex on the qemu VFIO
front. Not too sure how this is going to work on qemu-kvm? OR maybe it's
because I'm confused about the long term plan for user space [qemu vs
qemu-kvm] branch?
***One of the aspect I'm not clear is the strategy for device-assignment
under KVM?
A) Move to VFIO; [/dev/iommu, /dev/vfio]
B) KVM as a driver for the assigned devices; [sysfs/ ioctls..]
C) No plan for short term
Alex, Chris, Michael thanks for your reply.
-Etienne
On Tue, 26 Oct 2010, Michael S. Tsirkin wrote:
On Tue, Oct 26, 2010 at 09:41:12AM -0700, etmartin101 wrote:
Chris, Michael et al.
Part of the project I'm working on, we are looking at extending the
device assignment capabilities to provide support for PCIe AER.
Ideally, the host would register for AER (for every assigned
devices) and pass them up to Qemu.
As of now, one of the problem is that KVM is not a driver for the
assigned devices. I've seen Chris's slides from KVM conf 2010 but I
haven't seen any patches or discussion on that topic...
On another front, I've seen the work from Michael around 'uio_pci_generic'
and some of his comments:
" It's expected that more features of interest to virtualization will be
added to this driver in the future. Possibilities are: mmap for device
resources, MSI/MSI-X, eventfd (to interface with kvm), iommu."
I think that extending 'uio_pci_generic' to support AER is
relatively straight forward (assuming eventfd support from UIO).
Any thought?
thanks,
-Etienne
On the qemu side, patches for aer support are being worked on,
pls take a look, likely there's some synergy there.
On the kernel side, AER for uio sounds fine, but the features listed
above are not yet supported, so you'd have to code them up too.
There's a uiommu driver from Tom Lyon that does the iommu bit.
Alex and Tom have been working on a VFIO driver which is not based on
the uio framework. You can try joining forces.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
