From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nowgq-0000Up-Uw for qemu-devel@nongnu.org; Tue, 09 Mar 2010 05:29:28 -0500 Received: from [199.232.76.173] (port=35066 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nowgp-0000UE-Ki for qemu-devel@nongnu.org; Tue, 09 Mar 2010 05:29:27 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Nowgo-0002tD-A7 for qemu-devel@nongnu.org; Tue, 09 Mar 2010 05:29:27 -0500 Received: from mx1.redhat.com ([209.132.183.28]:64300) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Nowgn-0002sz-PH for qemu-devel@nongnu.org; Tue, 09 Mar 2010 05:29:26 -0500 Message-ID: <4B962301.3030008@redhat.com> Date: Tue, 09 Mar 2010 12:29:21 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1267833161-25267-1-git-send-email-cam@cs.ualberta.ca> <1267833161-25267-2-git-send-email-cam@cs.ualberta.ca> <4B94C9B3.1060904@redhat.com> <8286e4ee1003080957v9bb4837x187cebb8477348c2@mail.gmail.com> In-Reply-To: <8286e4ee1003080957v9bb4837x187cebb8477348c2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Cam Macdonell Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org On 03/08/2010 07:57 PM, Cam Macdonell wrote: > >> Can you provide a spec that describes the device? This would be useful for >> maintaining the code, writing guest drivers, and as a framework for review. >> > I'm not sure if you want the Qemu command-line part as part of the > spec here, but I've included for completeness. > I meant something from the guest's point of view, so command line syntax is less important. It should be equally applicable to a real PCI card that works with the same driver. See http://ozlabs.org/~rusty/virtio-spec/ for an example. > The Inter-VM Shared Memory PCI device > ----------------------------------------------------------- > > BARs > > The device supports two BARs. BAR0 is a 256-byte MMIO region to > support registers > (but might be extended in the future) > and BAR1 is used to map the shared memory object from the host. The size of > BAR1 is specified on the command-line and must be a power of 2 in size. > > Registers > > BAR0 currently supports 5 registers of 16-bits each. Suggest making registers 32-bits, friendlier towards non-x86. > Registers are used > for synchronization between guests sharing the same memory object when > interrupts are supported (this requires using the shared memory server). > How does the driver detect whether interrupts are supported or not? > When using interrupts, VMs communicate with a shared memory server that passes > the shared memory object file descriptor using SCM_RIGHTS. The server assigns > each VM an ID number and sends this ID number to the Qemu process along with a > series of eventfd file descriptors, one per guest using the shared memory > server. These eventfds will be used to send interrupts between guests. Each > guest listens on the eventfd corresponding to their ID and may use the others > for sending interrupts to other guests. > > enum ivshmem_registers { > IntrMask = 0, > IntrStatus = 2, > Doorbell = 4, > IVPosition = 6, > IVLiveList = 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. Writing to the 'Doorbell' register is how synchronization messages > are sent to other VMs. > > The IVPosition register is read-only and reports the guest's ID number. The > IVLiveList register is also read-only and reports a bit vector of currently > live VM IDs. > That limits the number of guests to 16. > The Doorbell register is 16-bits, but is treated as two 8-bit values. The > upper 8-bits are used for the destination VM ID. The lower 8-bits are 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 destination guest. > What happens when two interrupts are sent back-to-back to the same guest? Will the first status value be lost? Also, reading the status register requires a vmexit. I suggest dropping it and requiring the application to manage this information in the shared memory area (where it could do proper queueing of multiple messages). > A value of 255 in the upper 8-bits will trigger a broadcast where the message > will be sent to all other guests. > Please consider adding: - MSI support - interrupt on a guest attaching/detaching to the shared memory device With MSI you could also have the doorbell specify both guest ID and vector number, which may be useful. Thanks for this - it definitely makes reviewing easier. -- error compiling committee.c: too many arguments to function