From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cam Macdonell Subject: Re: [PATCH] Add shared memory PCI device that shares a memory object betweens VMs Date: Wed, 22 Apr 2009 16:41:53 -0600 Message-ID: <49EF9D31.4030605@cs.ualberta.ca> References: <1238600608-9120-1-git-send-email-cam@cs.ualberta.ca> <49D3965C.1030503@codemonkey.ws> <49D3AD79.7080708@redhat.com> <49D3B7ED.4030303@codemonkey.ws> <49EAFC44.9080809@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: subbu kl Return-path: Received: from fleet.cs.ualberta.ca ([129.128.22.22]:39300 "EHLO fleet.cs.ualberta.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752908AbZDVWmE (ORCPT ); Wed, 22 Apr 2009 18:42:04 -0400 Received: from fleet.cs.ualberta.ca (localhost.localdomain [127.0.0.1]) by fleet-spampd (Postfix) with ESMTP id D702E2803D for ; Wed, 22 Apr 2009 16:41:53 -0600 (MDT) In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: subbu kl wrote: > correct me if wrong, > can we do the sharing business by writing a non-transparent qemu PCI > device in host and guests can access each other's address space ? Hi Subbu, I'm a bit confused by your question. Are you asking how this device works or suggesting an alternative approach? I'm not sure what you mean by a non-transparent qemu device. Cam > > ~subbu > > On Sun, Apr 19, 2009 at 3:56 PM, Avi Kivity > wrote: > > Cameron Macdonell wrote: > > > Hi Avi and Anthony, > > Sorry for the top-reply, but we haven't discussed this aspect > here before. > > I've been thinking about how to implement interrupts. As far as > I can tell, unix domain sockets in Qemu/KVM are used > point-to-point with one VM being the server by specifying > "server" along with the unix: option. This works simply for two > VMs, but I'm unsure how this can extend to multiple VMs. How > would a server VM know how many clients to wait for? How can > messages then be multicast or broadcast? Is a separate > "interrupt server" necessary? > > > > I don't think unix provides a reliable multicast RPC. So yes, an > interrupt server seems necessary. > > You could expand its role an make it a "shared memory PCI card > server", and have it also be responsible for providing the backing > file using an SCM_RIGHTS fd. That would reduce setup headaches for > users (setting up a file for which all VMs have permissions). > > -- > Do not meddle in the internals of kernels, for they are subtle and > quick to panic. > > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > > -- > ~subbu