[Qemu-devel] Re: [RFC][PATCH v5 07/21] virtagent: add va.getfile RPC

[Michael Roth <mdroth@linux.vnet.ibm.com>]

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(<guest-path>,<host-path>) 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 (<offset>,<size>,<payload>)
>>> 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 (<file-size>,
>>> 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
>>
>