From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cam Macdonell Subject: Re: [PATCH v4 1/3] Device specification for shared memory PCI device Date: Mon, 12 Apr 2010 16:11:52 -0500 Message-ID: References: <1270680720-8457-1-git-send-email-cam@cs.ualberta.ca> <1270680720-8457-2-git-send-email-cam@cs.ualberta.ca> <4BC383D4.1090002@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org To: Avi Kivity Return-path: Received: from mail-pz0-f204.google.com ([209.85.222.204]:57812 "EHLO mail-pz0-f204.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752887Ab0DLVLx convert rfc822-to-8bit (ORCPT ); Mon, 12 Apr 2010 17:11:53 -0400 Received: by pzk42 with SMTP id 42so4225206pzk.4 for ; Mon, 12 Apr 2010 14:11:52 -0700 (PDT) In-Reply-To: <4BC383D4.1090002@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Apr 12, 2010 at 3:34 PM, Avi Kivity wrote: > On 04/08/2010 01:51 AM, Cam Macdonell wrote: > > (sorry about the late review) > >> + >> +Regular Interrupts >> +------------------ >> + >> +If regular interrupts are used (due to either a guest not supportin= g MSI >> or the >> +user specifying not to use them on startup) then the value written = to the >> lower >> +16-bits of the Doorbell register results is arbitrary and will trig= ger an >> +interrupt in the destination guest. >> > > Does the value written show up in the status register? =A0If yes, it = can get > overwritten by other interrupts. =A0If not, the lower 16 bits should = be > reserved to the value 1 for future expansion. =A0Basically it means t= hat the > pci interrupt is equivalent to to vector 1. The status register is only 1 or 0. I've made it so 1 is the only value written to trigger an interrupt. > >> + >> +An interrupt is also generated when a new guest accesses the shared >> memory >> +region. =A0A status of (2^32 - 1) indicates that a new guest has jo= ined. >> > > Suggest making this a bitfield, define bit 0 as 'at least some other = machine > has signalled you' and bit 1 as 'at least one other machine has joine= d'. > >> + >> +Message Signalled Interrupts >> +---------------------------- >> + >> +A ivshmem device may support multiple MSI vectors. =A0If so, the lo= wer >> 16-bits >> +written to the Doorbell register must be between 1 and the maximum = number >> of >> +vectors the guest supports. =A0The lower 16 bits written to the doo= rbell is >> the >> +MSI vector that will be raised in the destination guest. =A0The num= ber of >> MSI >> +vectors can vary but it is set when the VM is started, however vect= or 0 >> is >> +used to notify that a new guest has joined. =A0Guests should not us= e vector >> 0 for >> +any other purpose. >> > > Come to think about it, the guest has joined is actually pointless. =A0= Since > it hasn't initialized yet you can't talk to it. =A0So it's best to le= ave it > completely to the application, which can initialize shared memory and= start > sending interrupts. =A0An application defined protocol can handle joi= ning. Good point. > How is initialization performed? =A0I guess we can define memory to s= tart > zeroed and let participants compete to acquire a lock. No initialization of the memory occurs presently. With interrupts the shared memory server could zero the memory. Without the server (non-interrupt case) the guests can try and open the shared memory with O_EXCL first and zero the memory if it succeeds. If O_EXCL fails, then guest would open without O_EXCL and not initialize. > > Need to document the mask register. Currently only applies with regular interrupts. Since the status register is only 0 or 1, then only the first bit has any affect. I'll add this to the spec. > > Do we want an interrupt on a guest leaving? =A0Let's not complicate t= hings. Probably not if we don't have one on join. Cam From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O1QvJ-0004iq-OQ for qemu-devel@nongnu.org; Mon, 12 Apr 2010 17:12:01 -0400 Received: from [140.186.70.92] (port=56562 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O1QvI-0004hq-4G for qemu-devel@nongnu.org; Mon, 12 Apr 2010 17:12:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O1QvF-00088u-Tg for qemu-devel@nongnu.org; Mon, 12 Apr 2010 17:11:59 -0400 Received: from mail-pz0-f204.google.com ([209.85.222.204]:63697) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O1QvF-00088H-Jw for qemu-devel@nongnu.org; Mon, 12 Apr 2010 17:11:57 -0400 Received: by pzk42 with SMTP id 42so4225205pzk.4 for ; Mon, 12 Apr 2010 14:11:52 -0700 (PDT) MIME-Version: 1.0 Sender: camm@ualberta.ca In-Reply-To: <4BC383D4.1090002@redhat.com> References: <1270680720-8457-1-git-send-email-cam@cs.ualberta.ca> <1270680720-8457-2-git-send-email-cam@cs.ualberta.ca> <4BC383D4.1090002@redhat.com> Date: Mon, 12 Apr 2010 16:11:52 -0500 Message-ID: From: Cam Macdonell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] Re: [PATCH v4 1/3] Device specification for 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, kvm@vger.kernel.org On Mon, Apr 12, 2010 at 3:34 PM, Avi Kivity wrote: > On 04/08/2010 01:51 AM, Cam Macdonell wrote: > > (sorry about the late review) > >> + >> +Regular Interrupts >> +------------------ >> + >> +If regular interrupts are used (due to either a guest not supporting MS= I >> or the >> +user specifying not to use them on startup) then the value written to t= he >> lower >> +16-bits of the Doorbell register results is arbitrary and will trigger = an >> +interrupt in the destination guest. >> > > Does the value written show up in the status register? =A0If yes, it can = get > overwritten by other interrupts. =A0If not, the lower 16 bits should be > reserved to the value 1 for future expansion. =A0Basically it means that = the > pci interrupt is equivalent to to vector 1. The status register is only 1 or 0. I've made it so 1 is the only value written to trigger an interrupt. > >> + >> +An interrupt is also generated when a new guest accesses the shared >> memory >> +region. =A0A status of (2^32 - 1) indicates that a new guest has joined= . >> > > Suggest making this a bitfield, define bit 0 as 'at least some other mach= ine > has signalled you' and bit 1 as 'at least one other machine has joined'. > >> + >> +Message Signalled Interrupts >> +---------------------------- >> + >> +A ivshmem device may support multiple MSI vectors. =A0If so, the lower >> 16-bits >> +written to the Doorbell register must be between 1 and the maximum numb= er >> of >> +vectors the guest supports. =A0The lower 16 bits written to the doorbel= l is >> the >> +MSI vector that will be raised in the destination guest. =A0The number = of >> MSI >> +vectors can vary but it is set when the VM is started, however vector 0 >> is >> +used to notify that a new guest has joined. =A0Guests should not use ve= ctor >> 0 for >> +any other purpose. >> > > Come to think about it, the guest has joined is actually pointless. =A0Si= nce > it hasn't initialized yet you can't talk to it. =A0So it's best to leave = it > completely to the application, which can initialize shared memory and sta= rt > sending interrupts. =A0An application defined protocol can handle joining= . Good point. > How is initialization performed? =A0I guess we can define memory to start > zeroed and let participants compete to acquire a lock. No initialization of the memory occurs presently. With interrupts the shared memory server could zero the memory. Without the server (non-interrupt case) the guests can try and open the shared memory with O_EXCL first and zero the memory if it succeeds. If O_EXCL fails, then guest would open without O_EXCL and not initialize. > > Need to document the mask register. Currently only applies with regular interrupts. Since the status register is only 0 or 1, then only the first bit has any affect. I'll add this to the spec. > > Do we want an interrupt on a guest leaving? =A0Let's not complicate thing= s. Probably not if we don't have one on join. Cam