From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cam Macdonell Subject: Re: [PATCH RFC] Driver to support shared memory with interrupts with broadcast Date: Thu, 30 Jul 2009 14:36:01 -0600 Message-ID: <4A720431.6020407@cs.ualberta.ca> References: <1248972607-8818-1-git-send-email-cam@cs.ualberta.ca> <4A71E6A0.2080601@codemonkey.ws> <20090730202254.GA3949@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , kvm@vger.kernel.org To: "Michael S. Tsirkin" Return-path: Received: from fleet.cs.ualberta.ca ([129.128.22.22]:35035 "EHLO fleet.cs.ualberta.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751860AbZG3UgF (ORCPT ); Thu, 30 Jul 2009 16:36:05 -0400 In-Reply-To: <20090730202254.GA3949@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Michael S. Tsirkin wrote: > On Thu, Jul 30, 2009 at 01:29:52PM -0500, Anthony Liguori wrote: >> Cam Macdonell wrote: >>> This driver allows the guest VM to access shared memory between other guest >>> that is a POSIX shared memory object on the host. The driver can also send >>> interrupts by writing to the DoorBell register. >>> >>> With interrupts, the ioctl must specify the ID of the VM to receive the >>> interrupt or '255' for broadcast to all active VMs. The 'arg' parameter is the >>> destination VM and 'cmd' is the interrupt code. The value written to the >>> register is a bit messy. 32-bits are written to the register, the upper 16 are >>> the destination VM, and the lower 16 are the interrupt 'code' that the >>> destination guest will receive. Implemented codes (see the interrupt handler) >>> either call up on the device's semaphore or wake up on the wait_event queue. >>> These codes' uses are at the discretion of the driver so they could be >>> customized. >>> >>> For ioctls that read values from the device (such as for getting the global ID >>> of the guest) the arg parameter is unused. >>> >>> Cam >>> >> I think you should just use Michael's uio_pci driver. I don't think we >> have a need for a new kernel interface. > > If that's what you want to do, an example device that generates > interrupts in response to config writes can be found here: > http://www.archivum.info/qemu-devel@nongnu.org/2009-07/01548/%5BQemu-devel%5D_%5BPATCH%5D_qemu:_test-irq_device > Thank you, I'll have a look.