[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: [RFC][PATCH v5 07/21] virtagent: add va.getfile RPC
From: |
Adam Litke |
Subject: |
[Qemu-devel] Re: [RFC][PATCH v5 07/21] virtagent: add va.getfile RPC |
Date: |
Thu, 09 Dec 2010 08:40:24 -0600 |
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
- [Qemu-devel] Re: [RFC][PATCH v5 03/21] virtagent: common code for managing client/server rpc jobs, (continued)
[Qemu-devel] [RFC][PATCH v5 09/21] virtagent: add va.getdmesg RPC, Michael Roth, 2010/12/03
[Qemu-devel] [RFC][PATCH v5 08/21] virtagent: add agent_viewfile qmp/hmp command, Michael Roth, 2010/12/03