On Thu, Jul 23, 2009 at 1:36 PM, Jun Koi<junkoi2004@xxxxxxxxx> wrote: > On Wed, Jul 22, 2009 at 7:02 PM, Richard W.M. Jones<rjones@xxxxxxxxxx> 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 -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list