From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thiemo Seufer Subject: Re: [Qemu-devel] [PATCH] Vmchannel PCI device. Date: Mon, 15 Dec 2008 02:18:19 +0100 Message-ID: <20081215011819.GB12052@networkno.de> References: <20081214115027.4028.56164.stgit@dhcp-1-237.tlv.redhat.com> <20081214131247.GS5555@redhat.com> <49455B5E.8080504@codemonkey.ws> <20081214221346.GA16902@redhat.com> <49458F31.8040208@codemonkey.ws> <20081214233305.GA22151@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Anthony Liguori , qemu-devel@nongnu.org, Gleb Natapov , kvm@vger.kernel.org To: "Daniel P. Berrange" Return-path: Received: from relay01.mx.bawue.net ([193.7.176.67]:56682 "EHLO relay01.mx.bawue.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750950AbYLOBSW (ORCPT ); Sun, 14 Dec 2008 20:18:22 -0500 Content-Disposition: inline In-Reply-To: <20081214233305.GA22151@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Daniel P. Berrange wrote: [snip] > > If you don't have QEMU as a broker, it makes it very hard for QEMU to > > virtualization all of the resources exposed to the guest. This > > complicates things like save/restore and complicates security policies > > since you now have things being done on behalf of a guest originating > > from another process. It generally breaks the model of guest-as-a-process. > > This really depends on what you define the semantics of the vmchannel > protocol to be - specifically whether you want save/restore/migrate to > be totally opaque to the guest or not. I could imagine one option is to > have the guest end of the device be given -EPIPE when the backend is > restarted for restore/migrate, and choose to re-establish its connection > if so desired. This would not require QEMU to maintain any backend state. > For stateless datagram (UDP-like) application protocols there's nothing > that there's no special support required for save/restore. > > > What's the argument to do these things external to QEMU? > > There are many potential uses cases for VMchannel, Could you describe a practical use case of VMchannel in Qemu? I think I missed what this feature is good for. :-) > not all are going to be general purpose things that everyone wants to > use. If it is only good for specialized esoteric stuff, why should it be in Qemu? Thiemo