From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [RFC][PATCH 0/2] uq/master: Basic MSI support for in-kernel irqchip mode Date: Wed, 28 Mar 2012 11:45:00 +0200 Message-ID: <20120328094459.GB6194@redhat.com> References: <4F72BA12.2080309@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Avi Kivity , Marcelo Tosatti , qemu-devel , kvm@vger.kernel.org To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:31542 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751643Ab2C1Jos (ORCPT ); Wed, 28 Mar 2012 05:44:48 -0400 Content-Disposition: inline In-Reply-To: <4F72BA12.2080309@web.de> Sender: kvm-owner@vger.kernel.org List-ID: 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? 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? -- MST