Michael S. Tsirkin wrote:
On Tue, May 05, 2009 at 02:57:10PM +0300, Avi Kivity wrote:
Michael S. Tsirkin wrote:
On Tue, May 05, 2009 at 08:04:15AM -0300, Marcelo Tosatti wrote:
On Tue, May 05, 2009 at 01:30:28PM +0300, Michael S. Tsirkin wrote:
The new KVM_ASSIGN_SET_MSIX_NR and KVM_ASSIGN_SET_MSIX_ENTRY ioctls have
been merged for 2.6.30. However, I note that PCI spec allows devices to
support multiple vectors with MSI as well (support will be in linux
2.6.30).
Even though qemu for now only uses a single vector with MSI, it would
seem that it's better to make the kernel/user interface generic straight
away rather than add more ioctls later. What do you think? It might not
be too late to fix this for 2.6.30.
Can't you use more than one KVM_ASSIGN_SET_MSIX_ENTRY call per assigned
device?
Sure, but only one KVM_ASSIGN_SET_MSIX_NR.
MSIX_NR is the size of the table, while MSIX_ENTRY updates a single
entry, if I read the code correctly.
Right. So we'll need something like this for MSI as well.
Actually maybe MSIX_NR MSIX_ENTRY should be renamed to MSI_NR / MSI_ENTRY
and changed to do the right thing depending on the IRQ type?
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.
--
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
