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

[Adam Litke]

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 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