Re: [Qemu-devel] [RFC][PATCH 0/2] uq/master: Basic MSI support for in-kernel irqchip mode

[Michael S. Tsirkin]

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: <address@hidden>
> 
> 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