On 10/20/2010 12:44 PM, Michael S. Tsirkin wrote:
>
> Any performance numbers? What are the affected guests? just RHEL
> 4, or any others?
Likely any old linux.
I meant that people are likely to virtualize and expect high performance
from.
What about RHEL 3? Does it support msi? How about RHEL 5 - has it
fixed this problem?
> Alex, Michael, how would you do this with vfio?
With current VFIO we would catch mask writes in qemu and
call a KVM ioctl.
Doing what? Updating the irq routing to include/exclude the interrupt?
Disconnecting the irqfd?
Note you could disconnect the irqfd from either vfio or kvm.
We would also need an ioctl to retrieve
pending bits long term.
Suppose you disconnect the irqfd. Isn't the value of the eventfd
equivalent to the pending bit?
I think that it is unfortunate that we need to do this in userspace
while rest of configuration is done in kernel.
I would be much happier with userspace simply forwarding
everything to VFIO, so emulation does not have to
be split. That would be a clean interface: just mmap
MSIX BAR and forget about it.
Agree.
If instead of eventfd we had a file descriptor that can pass vector
information from vfio to kvm and back, that would fix it,
as we would not need to set us GSIs at all,
and not need for userspace to handle MSIX specially.
But if we emulate the entire msix bar in vfio, that's not needed, right?
How far away is vfio? If it's merged soon, we might avoid making
changes to the old assigned device infrastructure and instead update
vfio. On the other hand, changes to the old infrastructure are much
more amenable to backporting for long term support distro kernels, so we
may need to actively develop both for a while.
--
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
