On 10/24/2011 02:06 PM, Jan Kiszka wrote: > On 2011-10-24 13:09, Avi Kivity wrote: > > On 10/24/2011 12:19 PM, Jan Kiszka wrote: > >>> > >>> With the new feature it may be worthwhile, but I'd like to see the whole > >>> thing, with numbers attached. > >> > >> It's not a performance issue, it's a resource limitation issue: With the > >> new API we can stop worrying about user space device models consuming > >> limited IRQ routes of the KVM subsystem. > >> > > > > Only if those devices are in the same process (or have access to the > > vmfd). Interrupt routing together with irqfd allows you to disaggregate > > the device model. Instead of providing a competing implementation with > > new limitations, we need to remove the limitations of the old > > implementation. > > That depends on where we do the cut. Currently we let the IRQ source > signal an abstract edge on a pre-allocated pseudo IRQ line. But we > cannot build correct MSI-X on top of the current irqfd model as we lack > the level information (for PBA emulation). *) So we either need to > extend the existing model anyway -- or push per-vector masking back to > the IRQ source. In the latter case, it would be a very good chance to > give up on limited pseudo GSIs with static routes and do MSI messaging > from external IRQ sources to KVM directly. Good point. > > But all those considerations affect different APIs than what I'm > proposing here. We will always need a way to inject MSIs in the context > of the VM as there will always be scenarios where devices are better run > in that very same context, for performance or simplicity or whatever > reasons. E.g., I could imagine that one would like to execute an > emulated IRQ remapper rather in the hypervisor context than > "over-microkernelized" in a separate process. Right. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
