On Wed, Mar 28, 2012 at 09:13:22AM +0200, Jan Kiszka wrote: > On 2012-03-22 00:17, Jan Kiszka wrote: > > Some half a year ago when I posted my first attempt to refactor MSI > > for KVM support, we came to the conclusion that it might suffice to do > > transparent dynamic routing for user-space injected MSI messages. These > > two patches now implement such an approach for upstream. > > > > As QEMU does not yet include irqfd support (for vhost) or pci device > > assignment, this is already enough to enable MSI over the in-kernel > > irqchip. Still, this is only RFC as it is just lightly tested and should > > primarily collect feedback regarding the direction. If it's fine, I'd > > like to base further qemu-kvm refactorings and upstream preparations on > > top of such a series. > > > > Also, I'd like to reanimate my KVM patch to provide direct MSI injection > > in future kernels so that we do not need to take this long path here > > forever. > > > > Jan Kiszka (2): > > kvm: Introduce basic MSI support in-kernel irqchips > > KVM: x86: Wire up MSI support for in-kernel irqchip > > > > hw/apic.c | 3 + > > hw/kvm/apic.c | 33 ++++++++++- > > hw/pc.c | 5 -- > > kvm-all.c | 171 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++- > > kvm.h | 1 + > > 5 files changed, 205 insertions(+), 8 deletions(-) > > > > Anyone any comments? I think this series could open the door for > kernel_irqchip=on as default in QEMU 1.1. > > Jan > For what this patch is trying to do, would adding a simple ioctl for injecting a given message into guest be cleaner? Also, how would this support irqfd in the future? Will we have to rip it all out and replace with per-device tracking that we have today? -- MST -- 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
