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

[Jes Sorensen <Jes.Sorensen@redhat.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(<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?

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