From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gregory Haskins Subject: Re: [PATCH v2] Shared memory device with interrupt support Date: Mon, 18 May 2009 07:12:01 -0400 Message-ID: <4A114281.3070209@novell.com> References: <3D9CB4061D1EB3408D4A0B910433453C030BCA8892@inbmail01.lsi.com> <5A459472-C496-49ED-93D8-0C4CC391F50A@cs.ualberta.ca> <4A1086E6.30405@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig85EE8D02188B84AC2F9D5972" Cc: Cam Macdonell , "Kumar, Venkat" , "kvm@vger.kernel.org list" To: Avi Kivity Return-path: Received: from victor.provo.novell.com ([137.65.250.26]:59014 "EHLO victor.provo.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751466AbZERLMM (ORCPT ); Mon, 18 May 2009 07:12:12 -0400 In-Reply-To: <4A1086E6.30405@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig85EE8D02188B84AC2F9D5972 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Avi Kivity wrote: > Cam Macdonell wrote: >>> >>> If my understanding is correct both the VM's who wants to >>> communicate would gives this path in the command line with one of >>> them specifying as "server". >> >> Exactly, the one with the "server" in the parameter list will wait >> for a connection before booting. > > hm, we may be able to eliminate the server from the fast path, at the > cost of some complexity. > > When a guest connects to the server, the server creates an eventfd and > passes using SCM_RIGHTS to all other connected guests. The server > also passes the eventfds of currently connected guests to the new > guest. From now on, the server does not participate in anything; when > a quest wants to send an interrupt to one or more other guests, its > qemu just writes to the eventfds() of the corresponding guests; their > qemus will inject the interrupt, without any server involvement. > > Now, anyone who has been paying attention will have their alarms going > off at the word eventfd. And yes, if the host supports irqfd, the > various qemus can associate those eventfds with an irq and pretty much > forget about them. When a qemu triggers an irqfd, the interrupt will > be injected directly without the target qemu's involvement. I'll just add that you could tie the irqfd to an iosignalfd to eliminate the involvement of qemu on either side as well. I'm not sure if that really works with the design of this particular device (e.g. perhaps qemu is needed for other reasons besides signaling), but it is a neat demonstration of the flexibility of the newly emerging kvm-eventfd interfaces. -Greg --------------enig85EE8D02188B84AC2F9D5972 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoRQoEACgkQlOSOBdgZUxla7ACgiBr2RIK7/nkHF+HQxxPHI3IQ vCQAnR2ws8ldWRPW4J6TObRXq1Xs1o+W =LjJq -----END PGP SIGNATURE----- --------------enig85EE8D02188B84AC2F9D5972--