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 12:47:31 +0200 Message-ID: <20120328104731.GC6194@redhat.com> References: <4F72BA12.2080309@web.de> <20120328094459.GB6194@redhat.com> <4F72DEE3.4050704@siemens.com> 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]:36477 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757994Ab2C1KrV (ORCPT ); Wed, 28 Mar 2012 06:47:21 -0400 Content-Disposition: inline In-Reply-To: <4F72DEE3.4050704@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: 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