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

["Michael S. Tsirkin" <mst@redhat.com>]

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@redhat.com>

> 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