From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60512 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQPY4-0004nf-AI for qemu-devel@nongnu.org; Wed, 08 Dec 2010 14:19:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PQPY3-000062-6v for qemu-devel@nongnu.org; Wed, 08 Dec 2010 14:19:32 -0500 Received: from mx1.redhat.com ([209.132.183.28]:2890) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PQPY2-00005y-Uy for qemu-devel@nongnu.org; Wed, 08 Dec 2010 14:19:31 -0500 Message-ID: <4CFFDA39.20404@redhat.com> Date: Wed, 08 Dec 2010 20:19:21 +0100 From: Jes Sorensen 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> In-Reply-To: <1291737644.2174.15.camel@aglitke> Content-Type: text/plain; charset=UTF-8 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, Michael Roth , qemu-devel@nongnu.org, aliguori@linux.vnet.ibm.com, ryanh@us.ibm.com 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? 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