[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: |
Jes Sorensen |
Subject: |
[Qemu-devel] Re: [RFC][PATCH v5 07/21] virtagent: add va.getfile RPC |
Date: |
Wed, 08 Dec 2010 20:19:21 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) Gecko/20101103 Fedora/1.0-0.33.b2pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.6 |
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
- [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