From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Np3EL-0002cc-BR for qemu-devel@nongnu.org; Tue, 09 Mar 2010 12:28:29 -0500 Received: from [199.232.76.173] (port=56495 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Np3EK-0002c0-RV for qemu-devel@nongnu.org; Tue, 09 Mar 2010 12:28:28 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Np3EJ-0006dr-Um for qemu-devel@nongnu.org; Tue, 09 Mar 2010 12:28:28 -0500 Received: from mx20.gnu.org ([199.232.41.8]:9034) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Np3EH-0006ch-Bi for qemu-devel@nongnu.org; Tue, 09 Mar 2010 12:28:27 -0500 Received: from mx1.redhat.com ([209.132.183.28]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Np3E5-0006Zy-65 for qemu-devel@nongnu.org; Tue, 09 Mar 2010 12:28:13 -0500 Message-ID: <4B968521.7000208@redhat.com> Date: Tue, 09 Mar 2010 19:28:01 +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> In-Reply-To: <8286e4ee1003090727j1d45e5dq3bc5d2ae89c354c@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/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? >>> 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? >> > Right now, it would be. I believe that eventfd has a counting > semaphore option, that could prevent loss of status (but limits what > the status could be). > It only counts the number of interrupts (and kvm will coalesce them anyway). > My understanding of uio_pci interrupt handling > is fairly new, but we could have the uio driver store the interrupt > statuses to avoid losing them. > There's nowhere to store them if we use ioeventfd/irqfd. I think it's both easier and more efficient to leave this to the application (to store into shared memory). -- error compiling committee.c: too many arguments to function