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