Michael S. Tsirkin wrote:
Works for me. Sheng, is there a reason why it wasn't done like this?
btw, it could be further simplified by using irqfd. Instead of the host
device tying directly into kvm, it could just trigger an eventfd; and we
could terminate the eventfd either in kvm (irqfd) or in qemu.
If you are going wild, you could then split this code out from kvm
into something like a UIO driver. E.g. qemu could then in theory
support assigned devices even without VT-d hardware support in CPU.
That's my thinking. PCI interrupts don't work because we need to do
some hacky stuff in there, but MSI should. Oh, and we could improve UIO
support for interrupts when using MSI, since there's no need to
acknowledge the interrupt.
Support we can tell the kernel to signal an eventfd whenever an MSI
fires. We then ask kvm for an irqfd, and give that irqfd to the kernel
for the MSI.
Voila, we assign an interrupt from userspace, without the device or kvm
knowing anything about it. Like you say, we can assign the device to
pure qemu, or to a userspace driver.
Beautiful, I finally found something to replace my old Lego set.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
