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
