From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=53213 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQnf6-0003VI-Fv for qemu-devel@nongnu.org; Thu, 09 Dec 2010 16:04:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PQnel-0005eU-Pi for qemu-devel@nongnu.org; Thu, 09 Dec 2010 16:04:24 -0500 Received: from e9.ny.us.ibm.com ([32.97.182.139]:37586) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PQnel-0005eO-NA for qemu-devel@nongnu.org; Thu, 09 Dec 2010 16:04:03 -0500 Received: from d01dlp01.pok.ibm.com (d01dlp01.pok.ibm.com [9.56.224.56]) by e9.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id oB9KdULc020929 for ; Thu, 9 Dec 2010 15:41:25 -0500 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 14B7B728069 for ; Thu, 9 Dec 2010 16:04:03 -0500 (EST) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id oB9L424p323188 for ; Thu, 9 Dec 2010 16:04:02 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id oB9L41sA017401 for ; Thu, 9 Dec 2010 16:04:02 -0500 Message-ID: <4D014440.6050400@linux.vnet.ibm.com> Date: Thu, 09 Dec 2010 15:04:00 -0600 From: Michael Roth MIME-Version: 1.0 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> <1291905624.2260.2.camel@aglitke> In-Reply-To: <1291905624.2260.2.camel@aglitke> Content-Type: text/plain; charset=UTF-8; format=flowed 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: Adam Litke Cc: agl@linux.vnet.ibm.com, stefanha@linux.vnet.ibm.com, abeekhof@redhat.com, qemu-devel@nongnu.org, aliguori@linux.vnet.ibm.com, ryanh@us.ibm.com, Jes Sorensen On 12/09/2010 08:40 AM, Adam Litke wrote: > 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 also like the host-controlled mechanism. I think the difficulty is about the same either way though. Both would require an FD to be kept open, and some mechanism to read/seek in chunks and then send it back. I don't think this should replace the underlying RPC for viewfile however. I'd much rather it be an additional RPC, and we just put strict limits on the size of files viewfile/getfile can handle and make it clear that it is intended for quickly viewing text. I'll rename the getfile RPC to viewfile to make this a bit clearer as well. >> 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 >> >