From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] [PATCH] qemu: msi irq allocation api Date: Thu, 21 May 2009 16:06:58 +0300 Message-ID: <20090521130658.GE25309@redhat.com> References: <20090520162130.GA22109@redhat.com> <200905211301.52089.paul@codesourcery.com> <4A154432.1060808@redhat.com> <200905211329.41578.paul@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: qemu-devel@nongnu.org, Avi Kivity , Carsten Otte , kvm@vger.kernel.org, Rusty Russell , virtualization@lists.linux-foundation.org, Christian Borntraeger To: Paul Brook Return-path: Received: from mx2.redhat.com ([66.187.237.31]:40360 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754446AbZEUNKE (ORCPT ); Thu, 21 May 2009 09:10:04 -0400 Content-Disposition: inline In-Reply-To: <200905211329.41578.paul@codesourcery.com> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, May 21, 2009 at 01:29:37PM +0100, Paul Brook wrote: > On Thursday 21 May 2009, Avi Kivity wrote: > > Paul Brook wrote: > > >>>> In any case we need some internal API for this, and qemu_irq l= ooks > > >>>> like a good choice. > > >>> > > >>> What do you expect to be using this API? > > >> > > >> virtio, emulated devices capable of supporting MSI (e1000?), dev= ice > > >> assignment (not yet in qemu.git). > > > > > > It probably makes sense to have common infrastructure in pci.c to > > > expose/implement device side MSI functionality. However I see no = need for > > > a direct API between the device and the APIC. We already have an = API for > > > memory accesses and MMIO regions. I'm pretty sure a system could > > > implement MSI by pointing the device at system ram, and having th= e CPU > > > periodically poll that. > > > > Instead of writing directly, let's abstract it behind a qemu_set_ir= q(). > > This is easier for device authors. The default implementation of t= he > > irq callback could write to apic memory, while for kvm we can direc= tly > > trigger the interrupt via the kvm APIs. >=20 > I'm still not convinced. >=20 > A tight coupling between PCI devices and the APIC is just going to ca= use us=20 > problems later one. I'm going to come back to the fact that these are= memory=20 > writes so once we get IOMMU support they will presumably be subject t= o=20 > remapping by that, just like any other memory access. Actually, MSI messages are handled by IOMMU as interrupts, not as regular memory accesses. iommu book has comments such as =E2=80=A2 Interrupt addresses are never translated to memory addresses,= but other special address ranges may be reclaimed to be backed with memory. > Even ignoring that, qemu_irq isn't really the right interface. A MSI = is a one- > off event, not a level state. Yes, I just chose to ignore the level value. It does not look like such a big issue ... Do you advocate a new qemu_msi structure then? > OTOH stl_phys is exactly the right interface. Not really. These are writes but not into physical memory. =46or example, on intel 32 bit, stl_phys gets a 32 bit address, MSI writes encode the interrupt vector in high 32 bit bit of the address - way outside actual physical memory. > The KVM interface should be contained within the APIC implementation. >=20 > Paul Unfortunately kvm capabilities that are present in current kernels do not map well to this interface. You need to perform expensive set up for each interrupt vector you are going to use, be it MSI or regular interrupt. --=20 MST