On Tue, Aug 19, 2008 at 04:32:35PM -0400, Dave Anderson wrote: > Out of curiousity, any reason why a libvirt interface couldn't be > created that accesses guest pseudo-physical addresses? And does > the existing interface accept vmalloc addresses, or only unity-mapped > kernel virtual addresses? I'm afraid I didn't fully understand your previous comment about vmalloc & unity-mapped addresses. I'm not sure what a "unity-mapped" address is, and I thought vmalloc just used ordinary kernel addresses above PAGE_OFFSET. Anyway, in libvirt we rely on what the underlying hypervisor can do. In the case of QEMU/KVM, the QEMU monitor supports a simple "memsave" command. This command takes three parameters: start, size and a filename, and it saves the memory from start to start+size-1 into the file. Along the way it translates these virtual addresses through CR3 / the page tables (or the equivalent on non-x86 architectures). We could offer a way to get at physical addresses, but it would require getting a patch accepted into QEMU & KVM (separate but loosely synchronized codebases), and then a corresponding change in libvirt. Then there's a long wait while everyone updates to the newest versions of everything and finally physical memory peeking would be possible through libvirt. For the Xen driver's virDomainMemoryPeek call -- which isn't implemented in libvirt yet -- it's actually a lot easier to use physical addresses, because you request from the hypervisor that pages from another domain be mapped into your process using an ioctl which takes physical addresses. In order to provide compatibility with the existing software using virDomainMemoryPeek we were planning on implementing the page table lookups ourselves within libvirt. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
