From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [RFC][PATCH 0/2] uq/master: Basic MSI support for in-kernel irqchip mode Date: Wed, 28 Mar 2012 18:00:03 +0200 Message-ID: <4F733583.9060100@siemens.com> References: <4F72BA12.2080309@web.de> <20120328094459.GB6194@redhat.com> <4F72DEE3.4050704@siemens.com> <20120328104731.GC6194@redhat.com> <4F72F0FE.2010405@siemens.com> <20120328113139.GG6194@redhat.com> <4F72F7AF.4020309@siemens.com> <20120328154309.GB20176@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Avi Kivity , Marcelo Tosatti , qemu-devel , "kvm@vger.kernel.org" To: "Michael S. Tsirkin" Return-path: Received: from goliath.siemens.de ([192.35.17.28]:29593 "EHLO goliath.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758258Ab2C1QAQ (ORCPT ); Wed, 28 Mar 2012 12:00:16 -0400 In-Reply-To: <20120328154309.GB20176@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 2012-03-28 17:43, Michael S. Tsirkin wrote: > On Wed, Mar 28, 2012 at 01:36:15PM +0200, Jan Kiszka wrote: >> On 2012-03-28 13:31, Michael S. Tsirkin wrote: >>>>>>> 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? >> >> We will have two APIs depending on the source of the MSI. Special >> sources are the exception while emulated ones are the majority. And for >> the latter we should try very hard to keep things simple and clean. >> >> Jan > > I assume this means yes :) So how about we replace the hash table with a > single GSI reserved for this purpose, and use that for each interrupt? > This will work fine for slow paths such as hotplug controller, yes it > will be slow but *predictably* slow. AHCI, HDA, virtio-block, and every other userspace MSI user will suffer - I can't imagine you really want this. :) > > Fast path will use static GSIs like qemu-kvm does. Nope, qemu-kvm hooks deeply into the MSI layer to track vectors. I don't believe we want this upstream. It also doesn't work for non-PCI MSI (HPET on x86, try -global hpet.timers=4 -global hpet.msi=on with Linux guests). Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux