[Qemu-devel] Re: [PATCH 2/2] virtio: enable msi-x for console+balloon

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Dec 07, 2009 at 12:24:02PM +0100, Gerd Hoffmann wrote:
> On 12/07/09 11:59, Michael S. Tsirkin wrote:
>>> The motivation was to move them away from the ioapic, to reduce irq
>>> sharing of *other* devices which are connected to the ioapic too (i.e.
>>> usb, e1000, lsi, ...)
>>
>> Let's convert these to MSI instead?
>> This will likely pay off long term,
>> e.g. with nested virtualization.
>
> Works only of the real hardware we emulate can do MSI-X too, otherwise  
> guests simply wouldn't use it.

Sure. Naturally, improving IRQ routing so that e.g. lsi
and usb do not share an interrupt would also be a good idea
regardless.
Also - why not simply use virtio? I assume you are talking about
guests with virtio support otherwise MSI support in virtio
won't matter for them.

> I think the only case where this could  
> work out is e1000, newer revisions can do MSI-X.  Maybe also the  
> upcoming megasas emulation Hannes is working on.

Hmm. I would expect high-end storage to support MSI-X as well.
Could you point me to linux drivers for devices we emulate
so that I can check?

>>> I'm aware that these are not performance-critical.  I've even tried to
>>> use 'vectors=1' because of that.  I expected that would make them use
>>> MSI-X, but a single IRQ line only.  Didn't work though.  Intentional?
>>
>> So it's even worse, we are using up 2 vectors per device? Ugh ...
>
> Yes.  Three for balloon, but that can easily changed to two.

Yes, please, make this change for 0.12.

>> no way to distinguish between vq interrupt
>> and config change. This last thing is important
>> because it allows fastpath injection of MSI
>> interrupts directly from kernel without
>> notifying qemu to update IRQ field.
>
> Ah, *that* is the reason for the separate config interrupt.  Does the  
> in-kernel injection matter for balloon+console?

No, but changing this will need updating guests.
And if we do update guests anyway, I would suggest that
we put IRQ field in guest memory, with an atomic set,
and guest would get it with test and clear, so that
we get a generic interface and not something
specific for console/baloon.
Naturally, this needs a feature bit, and it won't happen
in 0.12/2.6.33 timeframe.


> I'd expect only  
> virtio-net needs that when it is configured with vhost?
>
> cheers
>   Gerd

Any other device will need the same if it has
a kernel backend.

-- 
MST