From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53286) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RY3c4-0006vP-7C for qemu-devel@nongnu.org; Tue, 06 Dec 2011 17:35:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RY3c2-0000VL-5e for qemu-devel@nongnu.org; Tue, 06 Dec 2011 17:35:48 -0500 Received: from mail-iy0-f173.google.com ([209.85.210.173]:37133) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RY3c1-0000Us-5C for qemu-devel@nongnu.org; Tue, 06 Dec 2011 17:35:46 -0500 Received: by iafj26 with SMTP id j26so755624iaf.4 for ; Tue, 06 Dec 2011 14:35:42 -0800 (PST) Message-ID: <4EDE98BA.9070902@codemonkey.ws> Date: Tue, 06 Dec 2011 16:35:38 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <20111205222208.31271.65662.stgit@ginnungagap.bsc.es> <20111205222312.31271.66303.stgit@ginnungagap.bsc.es> <4EDE7343.3010305@codemonkey.ws> <87ty5d1gfw.fsf@ginnungagap.bsc.es> In-Reply-To: <87ty5d1gfw.fsf@ginnungagap.bsc.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v2 4/5] backdoor: [softmmu] Add QEMU-side proxy to "libbackdoor.a" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-1?Q?Llu=EDs_Vilanova?= Cc: Blue Swirl , Zhi Yong Wu , Cam Macdonell , qemu-devel@nongnu.org On 12/06/2011 04:30 PM, Lluís Vilanova wrote: > Anthony Liguori writes: > >> I really worry about us introducing so many of these one-off paravirtual devices. >> I would much prefer that you look at doing this as an extension to the ivshmem >> device as it already has this sort of scope. You should be able to do this by >> just extending the size of bar 1 and using a well known guest id. > > I did in fact look at ivshmem some time ago, and it's true that both use the > same mechanisms; but each device has a completely different purpose. To me it > just seems that extending the control BAR in ivshmem to call the user-provided > backdoor callbacks is just conflating two completely separate devices into a > single one. Besides, I think that the qemu-side of the backdoor is simple enough > to avoid being a maintenance burden. They have the same purpose (which are both vague TBH). The only reason I'm sympathetic to this device is that virtio-serial has such insane semantics. It's bad enough we already have two "backdoor" mechanisms, adding a third seems insane to me. Regards, Anthony Liguori > > Another question would be to join both so that the backdoor can be used to > orchestrate operations between multiple VMs through ivshmem's server, but I > really have no time to look into that and don't even know whether it would then > make sense to join both devices. > > > Thanks, > Lluis >