On Wed, Mar 28, 2012 at 01:07:42PM +0200, Jan Kiszka wrote: > 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. Right. So static routes take precedence. This means that in effect we will have two APIs in qemu: for fast MSIs and for slow ones, the advantage of the slow APIs being that they are easier to use, right? > > > >> 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
