[libvirt] MemoryPeek() is slow

[Jun Koi]

On Thu, Jul 23, 2009 at 1:36 PM, Jun Koi<junkoi2004 at gmail.com> wrote:
> On Wed, Jul 22, 2009 at 7:02 PM, Richard W.M. Jones<rjones at redhat.com> wrote:
>> On Tue, Jul 21, 2009 at 07:39:07PM +0900, Jun Koi wrote:
>>> Hi,
>>>
>>> I play around with MemoryPeek() API on QEMU. While it works well, I
>>> found that it is too slow.
>>>
>>> That is expected because of the way it works: we always need to save
>>> memory to a file, and read it in again, and that is too inefficient.
>>
>> Yes this is correct, and works that way because of how the qemu
>> 'memsave' command works.
>>
>> Also there is a limit on the size of each peek (64K?) which is due to
>> the libvirt remote protocol, specifically the max message size.
>>
>>> I am trying to figure out a better way to do this. To do that, clearly
>>> we need to re-architecture QEMU for this: We must have another way to
>>> read memory from outside the QEMU process.
>>>
>>> Anybody could suggest a solution for this problem? I am willing to
>>> spend time on this feature to improve the situation.
>>
>> A better virDomainMemoryPeek / QEMU memsize would have the following
>> features:
>>
>> (1) Allow large chunks of memory to be snapshotted all in one go.
>> We'd still have to fetch them piece-by-piece because of the max
>> message size in the libvirt remote protocol, but at least the single
>> large snapshot would be more consistent.
>>
>> (2) Don't use the temporary file (?)
>>
>> (3) Be faster, eg. in the non-remote case.
>>
>> (4) Work with Xen and other hypervisors ...
>>
>> (5) Work with physical memory, virtual memory and registers.
>>
>
> On (5): that requires another API, not this virDomainMemoryPeek()

I mean the registers part need a new API.

Thanks,
J