[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: [PATCH 2/2] virtio: enable msi-x for console+balloon
From: |
Michael S. Tsirkin |
Subject: |
[Qemu-devel] Re: [PATCH 2/2] virtio: enable msi-x for console+balloon |
Date: |
Mon, 7 Dec 2009 15:03:29 +0200 |
User-agent: |
Mutt/1.5.19 (2009-01-05) |
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
- [Qemu-devel] Re: [PATCH 2/2] virtio: enable msi-x for console+balloon, Michael S. Tsirkin, 2009/12/07
- [Qemu-devel] Re: [PATCH 2/2] virtio: enable msi-x for console+balloon, Gerd Hoffmann, 2009/12/07
- [Qemu-devel] Re: [PATCH 2/2] virtio: enable msi-x for console+balloon, Michael S. Tsirkin, 2009/12/07
- [Qemu-devel] Re: [PATCH 2/2] virtio: enable msi-x for console+balloon, Gerd Hoffmann, 2009/12/07
- [Qemu-devel] Re: [PATCH 2/2] virtio: enable msi-x for console+balloon,
Michael S. Tsirkin <=
- [Qemu-devel] Re: [PATCH 2/2] virtio: enable msi-x for console+balloon, Gerd Hoffmann, 2009/12/07
- [Qemu-devel] Re: [PATCH 2/2] virtio: enable msi-x for console+balloon, Michael S. Tsirkin, 2009/12/07
- [Qemu-devel] Re: [PATCH 2/2] virtio: enable msi-x for console+balloon, Gerd Hoffmann, 2009/12/07
- [Qemu-devel] Re: [PATCH 2/2] virtio: enable msi-x for console+balloon, Michael S. Tsirkin, 2009/12/07