Re: [PATCH 0/8][v2] MSI-X mask emulation support for assigned device

Avi Kivity
2010-10-20T10:59:47Z

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