From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] Inter-VM shared memory PCI device Date: Tue, 09 Mar 2010 19:28:01 +0200 Message-ID: <4B968521.7000208@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org To: Cam Macdonell Return-path: Received: from mx1.redhat.com ([209.132.183.28]:27884 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751113Ab0CIR2N (ORCPT ); Tue, 9 Mar 2010 12:28:13 -0500 In-Reply-To: <8286e4ee1003090727j1d45e5dq3bc5d2ae89c354c@mail.gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: 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