On 2012-03-28 12:47, Michael S. Tsirkin wrote: > 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> Cannot match this ID, but I guess the best is now to just leave a flags and some padding fields in the struct for whatever may or may not come in the future. > >> 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? This is about the kernel IRQ chip support. We want to support it over current kernels, not only 3.4 or even later. > >>> 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? As done in my original series: If a static route requires a pseudo GSI and there are none free, we simply flush the dynamic MSI routes. > >> 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? Basically yes, but with refactored interfaces. E.g. all pseudo GSI management will be privatized in the KVM layer. And MSI[-X] interfaces will be refactored to reduce the code you need in virtio and pci-assign for propagating vector changes to the routing subsystem. Details regarding this aren't settled yet, but it will be just an add-on to the MSI injection path for fully emulated devices, ie. the topic of this series. Jan -- 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
