From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M7CBq-0008Jp-U4 for qemu-devel@nongnu.org; Thu, 21 May 2009 13:36:22 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M7CBm-0008Hb-CX for qemu-devel@nongnu.org; Thu, 21 May 2009 13:36:22 -0400 Received: from [199.232.76.173] (port=40195 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M7CBm-0008HY-6w for qemu-devel@nongnu.org; Thu, 21 May 2009 13:36:18 -0400 Received: from mx2.redhat.com ([66.187.237.31]:37040) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M7CBl-0006Q7-P4 for qemu-devel@nongnu.org; Thu, 21 May 2009 13:36:18 -0400 Date: Thu, 21 May 2009 20:33:08 +0300 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] [PATCH] qemu: msi irq allocation api Message-ID: <20090521173308.GA7722@redhat.com> References: <20090520162130.GA22109@redhat.com> <20090521131231.GH25309@redhat.com> <200905211423.20843.paul@codesourcery.com> <200905211431.27287.paul@codesourcery.com> <20090521164520.GA6474@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20090521164520.GA6474@redhat.com> Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Carsten Otte , kvm@vger.kernel.org, Rusty Russell , qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org, Christian Borntraeger , Avi Kivity On Thu, May 21, 2009 at 07:45:20PM +0300, Michael S. Tsirkin wrote: > On Thu, May 21, 2009 at 02:31:26PM +0100, Paul Brook wrote: > > On Thursday 21 May 2009, Paul Brook wrote: > > > > > MSI provides multiple edge triggered interrupts, whereas tradit= ional > > > > > mode provides a single level triggered interrupt. My guess is m= ost > > > > > devices will want to treat these differently anyway. > > > > > > > > So, is qemu_send_msi better than qemu_set_irq. > > > > > > Neither. pci_send_msi, which is a trivial wrapper around stl_phys. > >=20 > > To clarify, you seem to be trying to fuse two largely separate featur= es=20 > > together. > >=20 > > MSI is a standard PCI device capability[1] that involves the device p= erforming=20 > > a 32-bit memory write when something interesting occurs. These writes= may or=20 > > may not be directed at a APIC. > >=20 > > The x86 APIC has a memory mapped interface that allows generation of = CPU=20 > > interrupts in response response to memory writes. These may or may no= t come=20 > > from an MSI capable PCI device. > >=20 > > Paul > >=20 > > [1] Note a *device* capability, not a bus capability. >=20 > Paul, so I went over specs, and what you say about APIC here does not > seem to be what Intel actually implemented. Specifically, Intel > implemented *MSI support in APIC*. This lets PCI devices, but not the C= PU, > signal interrupts by memory writes. >=20 > For example, after reset, when CPU writes to address 0xfee00000 this > is an access to a reserved register in APIC, but when PCI device > does write to 0xfee00000, this triggers an interrupt to destination 0. >=20 > See section 9.12 in Intel=C2=AE 64 and IA-32 Architectures Software > Developer=E2=80=99s Manual Volume 3A: System Programming Guide, Part 1 > http://www.intel.com/Assets/PDF/manual/253668.pdf >=20 > So it seems that what we need to do in pci is: >=20 > if (!msi_ops || msi_ops->send_msi(address, data)) > stl_phy(address, data); >=20 > where send_msi is wired to apic_send_msi and > where apic_send_msi returns an error for an address > outside of the MSI range 0xfee00000 - 0xfeefffff >=20 > Makes sense? So I ended up with these ops: allocate free update send which APIC will define and MSI emulation will use. Here, send will return error for addresses outside 0xfeexxxxx range, and device will do a plain stl_phy. --=20 MST