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/