From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] Add shared memory PCI device that shares a memory object betweens VMs Date: Sun, 19 Apr 2009 13:26:12 +0300 Message-ID: <49EAFC44.9080809@redhat.com> References: <1238600608-9120-1-git-send-email-cam@cs.ualberta.ca> <49D3965C.1030503@codemonkey.ws> <49D3AD79.7080708@redhat.com> <49D3B7ED.4030303@codemonkey.ws> 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: Cameron Macdonell Return-path: Received: from mx2.redhat.com ([66.187.237.31]:42217 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752396AbZDSK0V (ORCPT ); Sun, 19 Apr 2009 06:26:21 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 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.