Re: [Qemu-devel] Kernel memory allocation debugging with Qemu

[Paul Brook <paul@codesourcery.com>]

> The patch takes a half of the memory and slows down the system. I
> think Qemu could be used instead. A channel (IO/MMIO) is created
> between the memory allocator in target kernel and Qemu running in the
> host. Memory allocator tells the allocated area to Qemu using the
> channel. Qemu changes the physical memory mapping for the area to
> special memory that will report any reads before writes back to
> allocator. Writes change the memory back to standard RAM. The
> performance would be comparable to Qemu in general and host kernel +
> Qemu only take a few MB of the memory. The system would be directly
> usable for other OSes as well.

The qemu implementation isn't actually any more space efficient than the 
in-kernel implementation. You still need the same amount of bookkeeping ram. 
In both cases it should be possible to reduce the overhead from 1/2 to 1/9 by 
using a bitmask rather than whole bytes.

Performance is a less clear. A qemu implementation probably causes less 
relative slowdown than an in-kernel implementation. However it's still going 
to be significantly slower than normal qemu.  Remember that any checked 
access is going to have to go through the slow case in the TLB lookup. Any 
optimizations that are applicable to one implementation can probably also be 
applied to the other.

Given qemu is significantly slower to start with, and depending on the 
overhead of taking the page fault, it might not end up much better overall. A 
KVM implementation would most likely be slower than the in-kernel.

That said it may be an interesting thing to play with. In practice it's 
probably most useful to generate an interrupt and report back to the guest 
OS, rather than having qemu reports faults directly.

Paul