Re: [libvirt] MemoryPeek() is slow

On Wed, Jul 22, 2009 at 7:02 PM, Richard W.M. Jones<rjones(a)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()