From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=43743 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQhfc-0003f8-M9 for qemu-devel@nongnu.org; Thu, 09 Dec 2010 09:40:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PQhfb-0007Cc-HG for qemu-devel@nongnu.org; Thu, 09 Dec 2010 09:40:32 -0500 Received: from e7.ny.us.ibm.com ([32.97.182.137]:52869) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PQhfb-0007CW-Ec for qemu-devel@nongnu.org; Thu, 09 Dec 2010 09:40:31 -0500 Received: from d01dlp01.pok.ibm.com (d01dlp01.pok.ibm.com [9.56.224.56]) by e7.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id oB9ELiw7011038 for ; Thu, 9 Dec 2010 09:22:53 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 881F3728065 for ; Thu, 9 Dec 2010 09:40:29 -0500 (EST) Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id oB9EeTxh170350 for ; Thu, 9 Dec 2010 09:40:29 -0500 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id oB9EeSaS027566 for ; Thu, 9 Dec 2010 07:40:28 -0700 From: Adam Litke In-Reply-To: <4CFFDA39.20404@redhat.com> References: <1291399402-20366-1-git-send-email-mdroth@linux.vnet.ibm.com> <1291399402-20366-8-git-send-email-mdroth@linux.vnet.ibm.com> <4CFE4234.9020305@redhat.com> <1291737644.2174.15.camel@aglitke> <4CFFDA39.20404@redhat.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 09 Dec 2010 08:40:24 -0600 Message-ID: <1291905624.2260.2.camel@aglitke> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [RFC][PATCH v5 07/21] virtagent: add va.getfile RPC List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jes Sorensen Cc: agl@linux.vnet.ibm.com, stefanha@linux.vnet.ibm.com, abeekhof@redhat.com, Michael Roth , qemu-devel@nongnu.org, aliguori@linux.vnet.ibm.com, ryanh@us.ibm.com On Wed, 2010-12-08 at 20:19 +0100, Jes Sorensen wrote: > On 12/07/10 17:00, Adam Litke wrote: > > Hi Jes, you raise some good points and pitfalls with the current getfile > > approach. I've been thinking about an alternative and am wondering what > > you (and others) think... > > > > First off, I think we should switch to a copyfile() API that allows us > > to avoid presenting the file contents to the user. Neither the human > > monitor nor the control monitor are designed to be file pagers. Let the > > user decide how to consume the data once it has been transferred. Now > > we don't need to care if the file is binary or text. > > > > The virtagent RPC protocol is bi-directional and supports asynchronous > > events. We can use these to implement a better copyfile RPC that can > > transfer larger files without wasting memory. The host issues a > > copyfile(, ) RPC. The immediate result of this > > call will indicate whether the guest is able to initiate the transfer. > > The guest will generate a series of events (, , ) > > until the entire contents has been transferred. The host and guest > > could negotiate the chunk size if necessary. Once the transfer is > > complete, the guest sends a final event to indicate this (, > > 0). > > > > This interface could be integrated into the monitor with a pair of > > commands (va_copyfile and info va_copyfile), the former used to initiate > > transfers and the latter to check on the status. > > > > Thoughts on this? > > Hi Adam, > > This sounds a lot safer than the current approach. Intuitively I would > think it should be the host controlling the copy, but otherwise it > sounds good. Or is there a reason why the guest should control it? Actually, a host-controlled interface would be both simpler to implement (on both ends) and would concentrate control in the host (which is what we probably want anyway). > I think it is vital that we do it in a way where a copy cannot blow > QEMU's memory consumption out of the water, but the approach you suggest > seems to take care of that. > > Cheers, > Jes > -- Thanks, Adam