On Wed, Mar 28, 2012 at 11:50:27AM +0200, Jan Kiszka wrote: > On 2012-03-28 11:45, Michael S. Tsirkin wrote: > > 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? > > For sure, and I already proposed this in the past. I think we were only > discussing the extensibility of such an IOCTL. Yes. And the conclusion I think was that it's not very extensible but a very good fit for what we want to do, right? See Message-ID: <4EA66B99.3010205@xxxxxxxxxx> > Anyway, that won't help with existing kernels. That's why I'm proposing > this userspace approach as an interim solution. I guess we can just keep the userspace irqchip around? > > 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? > > Irqfd and kvm device assignment will require additional interfaces (of > the kvm core in QEMU) via which you will be able to request stable > routes from such sources to specified MSIs. That will be widely > orthogonal to what is done in these patches here. Yes but not exactly as they will conflict for resources, right? How do you plan to solve this? > Upstream is not > affected yet as it neither supports device assignment nor irqfds up to now. > > Jan Just to clarify: so in the end, we will need to basically do what qemu-kvm does, as well? > -- > Siemens AG, Corporate Technology, CT T DE IT 1 > Corporate Competence Center Embedded Linux -- 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
