On Mon, Dec 07, 2009 at 11:32:36AM +0100, Gerd Hoffmann wrote: > On 12/07/09 10:37, Michael S. Tsirkin wrote: >> >> Sorry, I missed this the first time this was posted, and I see this in >> staging now. Gerd, could you please explain the motivation for this >> patch? >> >> I assumed console/baloon interrupts are not performance critical, so >> would we not be better off using a shared interrupt for these, >> reserving MSI vectors for where performance matters? > > 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. > > 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 ... vectors=1 currently will make guest fall back on regular interrupts, because IRQ field is undefined when MSI is used, so there is 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. Maybe we can define something special for a single vector, but this is not a use case I considered so will need guest changes ... > cheers, > Gerd
