From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NpcCy-0004mL-Bm for qemu-devel@nongnu.org; Thu, 11 Mar 2010 01:49:24 -0500 Received: from [199.232.76.173] (port=39118 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NpcCx-0004lV-Ir for qemu-devel@nongnu.org; Thu, 11 Mar 2010 01:49:23 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NpcCw-00069T-N1 for qemu-devel@nongnu.org; Thu, 11 Mar 2010 01:49:23 -0500 Received: from mx1.redhat.com ([209.132.183.28]:32228) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NpcCw-00069P-BL for qemu-devel@nongnu.org; Thu, 11 Mar 2010 01:49:22 -0500 Message-ID: <4B989264.5020609@redhat.com> Date: Thu, 11 Mar 2010 08:49:08 +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> <4B962301.3030008@redhat.com> <8286e4ee1003090724m1ef0b571g8b705a24e36e1753@mail.gmail.com> <8286e4ee1003090727j1d45e5dq3bc5d2ae89c354c@mail.gmail.com> <4B968521.7000208@redhat.com> <8286e4ee1003091034n236f1c07w6b121d76f138e706@mail.gmail.com> <4B9764A9.9050003@redhat.com> <8286e4ee1003100836g35da5f07ye01fe272dee18dc2@mail.gmail.com> In-Reply-To: <8286e4ee1003100836g35da5f07ye01fe272dee18dc2@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/10/2010 06:36 PM, Cam Macdonell wrote: > On Wed, Mar 10, 2010 at 2:21 AM, Avi Kivity wrote: > >> On 03/09/2010 08:34 PM, Cam Macdonell wrote: >> >>> On Tue, Mar 9, 2010 at 10:28 AM, Avi Kivity wrote: >>> >>> >>>> On 03/09/2010 05:27 PM, Cam Macdonell wrote: >>>> >>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>>> 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? >>>>>> >>>>>> >>>>>> >>>>> At the moment, the VM ID is set to -1 if interrupts aren't supported, >>>>> but that may not be the clearest way to do things. With UIO is there >>>>> a way to detect if the interrupt pin is on? >>>>> >>>>> >>>>> >>>> I suggest not designing the device to uio. Make it a good >>>> guest-independent >>>> device, and if uio doesn't fit it, change it. >>>> >>>> Why not support interrupts unconditionally? Is the device useful without >>>> interrupts? >>>> >>>> >>> Currently my patch works with or without the shared memory server. If >>> you give the parameter >>> >>> -ivshmem 256,foo >>> >>> then this will create (if necessary) and map /dev/shm/foo as the >>> shared region without interrupt support. Some users of shared memory >>> are using it this way. >>> >>> Going forward we can require the shared memory server and always have >>> interrupts enabled. >>> >>> >> Can you explain how they synchronize? Polling? Using the network? Using >> it as a shared cache? >> >> If it's a reasonable use case it makes sense to keep it. >> >> > Do you mean how they synchronize without interrupts? One project I've > been contacted about uses the shared region directly for > synchronization for simulations running in different VMs that share > data in the memory region. In my tests spinlocks in the shared region > work between guests. > I see. > If we want to keep the serverless implementation, do we need to > support shm_open with -chardev somehow? Something like -chardev > shm,name=foo. Right now my qdev implementation just passes the name > to the -device option and opens it. > I think using the file name is fine. >> Another thing comes to mind - a shared memory ID, in case a guest has >> multiple cards. >> > Sure, a number that can be passed on the command-line and stored in a register? > Yes. NICs use the MAC address and storage uses the disk serial number, this is the same thing for shared memory. -- error compiling committee.c: too many arguments to function