Re: [Qemu-devel] [RFC][PATCH 28/45] qemu-kvm: msix: Drop tracking of used vectors

[Michael S. Tsirkin]

On Tue, Oct 18, 2011 at 05:55:54PM +0200, Jan Kiszka wrote:
> On 2011-10-18 17:22, Jan Kiszka wrote:
> > What KVM has to do is just mapping an arbitrary MSI message
> > (theoretically 64+32 bits, in practice it's much of course much less) to
> 
> ( There are 24 distinguishing bits in an MSI message on x86, but that's
> only a current interpretation of one specific arch. )

Confused. vector mask is 8 bits. the rest is destination id etc.

> > a single GSI and vice versa. As there are less GSIs than possible MSI
> > messages, we could run out of them when creating routes, statically or
> > lazily.
> > 
> > What would probably help us long-term out of your concerns regarding
> > lazy routing is to bypass that redundant GSI translation for dynamic
> > messages, i.e. those that are not associated with an irqfd number or an
> > assigned device irq. Something like a KVM_DELIVER_MSI IOCTL that accepts
> > address and data directly.
> 
> This would be a trivial extension in fact. Given its beneficial impact
> on our GSI limitation issue, I think I will hack up something like that.
> 
> And maybe this makes a transparent cache more reasonable. Then only old
> host kernels would force us to do searches for already cached messages.
> 
> Jan

Hmm, I'm not all that sure. Existing design really allows
caching the route in various smart ways. We currently do
this for irqfd but this can be extended to ioctls.
If we just let the guest inject arbitrary messages,
that becomes much more complex.

Another concern is mask bit emulation. We currently
handle mask bit in userspace but patches
to do them in kernel for assigned devices where seen
and IMO we might want to do that for virtio as well.

For that to work the mask bit needs to be tied to
a specific gsi or specific device, which does not
work if we just inject arbitrary writes.

-- 
MST