From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Np2YF-0003cB-1c for qemu-devel@nongnu.org; Tue, 09 Mar 2010 11:44:59 -0500 Received: from [199.232.76.173] (port=40242 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Np2YE-0003bG-DM for qemu-devel@nongnu.org; Tue, 09 Mar 2010 11:44:58 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Np2YC-0001bG-R1 for qemu-devel@nongnu.org; Tue, 09 Mar 2010 11:44:58 -0500 Received: from mail-iw0-f176.google.com ([209.85.223.176]:39164) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Np2YC-0001b2-Hc for qemu-devel@nongnu.org; Tue, 09 Mar 2010 11:44:56 -0500 Received: by iwn6 with SMTP id 6so3768510iwn.4 for ; Tue, 09 Mar 2010 08:44:55 -0800 (PST) MIME-Version: 1.0 Sender: camm@ualberta.ca In-Reply-To: <4B964709.6040202@redhat.com> References: <1267833161-25267-1-git-send-email-cam@cs.ualberta.ca> <4B94C9B3.1060904@redhat.com> <8286e4ee1003080957v9bb4837x187cebb8477348c2@mail.gmail.com> <201003091349.51344.arnd@arndb.de> <4B964709.6040202@redhat.com> Date: Tue, 9 Mar 2010 09:44:54 -0700 Message-ID: <8286e4ee1003090844hb97d1c6lfd1216faf945a323@mail.gmail.com> From: Cam Macdonell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] Re: [PATCH] Inter-VM shared memory PCI device List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: qemu-devel@nongnu.org, Arnd Bergmann , kvm@vger.kernel.org On Tue, Mar 9, 2010 at 6:03 AM, Avi Kivity wrote: > On 03/09/2010 02:49 PM, Arnd Bergmann wrote: >> >> On Monday 08 March 2010, Cam Macdonell wrote: >> >>> >>> enum ivshmem_registers { >>> =A0 =A0 IntrMask =3D 0, >>> =A0 =A0 IntrStatus =3D 2, >>> =A0 =A0 Doorbell =3D 4, >>> =A0 =A0 IVPosition =3D 6, >>> =A0 =A0 IVLiveList =3D 8 >>> }; >>> >>> The first two registers are the interrupt mask and status registers. >>> Interrupts are triggered when a message is received on the guest's >>> eventfd from >>> another VM. =A0Writing to the 'Doorbell' register is how synchronizatio= n >>> messages >>> are sent to other VMs. >>> >>> The IVPosition register is read-only and reports the guest's ID number. >>> =A0The >>> IVLiveList register is also read-only and reports a bit vector of >>> currently >>> live VM IDs. >>> >>> The Doorbell register is 16-bits, but is treated as two 8-bit values. >>> =A0The >>> upper 8-bits are used for the destination VM ID. =A0The lower 8-bits ar= e >>> the >>> value which will be written to the destination VM and what the guest >>> status >>> register will be set to when the interrupt is trigger is the destinatio= n >>> guest. >>> A value of 255 in the upper 8-bits will trigger a broadcast where the >>> message >>> will be sent to all other guests. >>> >> >> This means you have at least two intercepts for each message: >> >> 1. Sender writes to doorbell >> 2. Receiver gets interrupted >> >> With optionally two more intercepts in order to avoid interrupting the >> receiver every time: >> >> 3. Receiver masks interrupt in order to process data >> 4. Receiver unmasks interrupt when it's done and status is no longer >> pending >> >> I believe you can do much better than this, you combine status and mask >> bits, making this level triggered, and move to a bitmask of all guests: >> >> In order to send an interrupt to another guest, the sender first checks >> the bit for the receiver. If it's '1', no need for any intercept, the >> receiver will come back anyway. If it's zero, write a '1' bit, which >> gets OR'd into the bitmask by the host. The receiver gets interrupted >> at a raising edge and just leaves the bit on, until it's done processing= , >> then turns the bit off by writing a '1' into its own location in the mas= k. >> > > We could make the masking in RAM, not in registers, like virtio, which wo= uld > require no exits. =A0It would then be part of the application specific > protocol and out of scope of of this spec. > This kind of implementation would be possible now since with UIO it's up to the application whether to mask interrupts or not and what interrupts mean. We could leave the interrupt mask register for those who want that behaviour. Arnd's idea would remove the need for the Doorbell and Mask, but we will always need at least one MMIO register to send whatever interrupts we do send. Cam