From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC][PATCH] KVM: Introduce direct MSI message injection for in-kernel irqchips Date: Tue, 25 Oct 2011 09:56:09 +0200 Message-ID: <4EA66B99.3010205@redhat.com> References: <4EA13917.7070401@siemens.com> <4EA533B8.4040407@redhat.com> <4EA53BBF.2010704@siemens.com> <4EA54759.902@redhat.com> <4EA554B0.7030808@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , kvm , "Michael S. Tsirkin" To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:27862 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752816Ab1JYH4N (ORCPT ); Tue, 25 Oct 2011 03:56:13 -0400 In-Reply-To: <4EA554B0.7030808@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On 10/24/2011 02:06 PM, Jan Kiszka wrote: > On 2011-10-24 13:09, Avi Kivity wrote: > > On 10/24/2011 12:19 PM, Jan Kiszka wrote: > >>> > >>> With the new feature it may be worthwhile, but I'd like to see the whole > >>> thing, with numbers attached. > >> > >> It's not a performance issue, it's a resource limitation issue: With the > >> new API we can stop worrying about user space device models consuming > >> limited IRQ routes of the KVM subsystem. > >> > > > > Only if those devices are in the same process (or have access to the > > vmfd). Interrupt routing together with irqfd allows you to disaggregate > > the device model. Instead of providing a competing implementation with > > new limitations, we need to remove the limitations of the old > > implementation. > > That depends on where we do the cut. Currently we let the IRQ source > signal an abstract edge on a pre-allocated pseudo IRQ line. But we > cannot build correct MSI-X on top of the current irqfd model as we lack > the level information (for PBA emulation). *) So we either need to > extend the existing model anyway -- or push per-vector masking back to > the IRQ source. In the latter case, it would be a very good chance to > give up on limited pseudo GSIs with static routes and do MSI messaging > from external IRQ sources to KVM directly. Good point. > > But all those considerations affect different APIs than what I'm > proposing here. We will always need a way to inject MSIs in the context > of the VM as there will always be scenarios where devices are better run > in that very same context, for performance or simplicity or whatever > reasons. E.g., I could imagine that one would like to execute an > emulated IRQ remapper rather in the hypervisor context than > "over-microkernelized" in a separate process. Right. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.