Re: [Qemu-devel] [RFC] Host vs Guest memory allocation

[Paul Brook <paul@codesourcery.com>]

> The Problem:
> 
> CONFIG_USER_ONLY kinda sorta tries to manage the distinction between
> qemu memory and guest memory. This can be seen in the PAGE_RESERVED
> frobbing and qemu_malloc etc. However, it doesn't handle random malloc
> calls eg from libc itself or other libraries in use.
> 
> Possible solutions:
> 
> There are several possible solutions as I see it, each depending on the
> pairing of host and guest address space characteristics:
> 
> (0) Do nothing.  That is, don't even pretend to record host memory and
>     validate guest access that may or may not overlap.  To my mind this
>     is in fact an improvement over the kinda-sorta solution we have now.

This is effectively what we do now, the PAGE_RESERVED bits aren't used for 
anything interesting.  Any guest application that makes assumptions about 
address space availability (i.e. maps at hardcoded addresses) is already 
likely to be broken on many native kernels. target_mmap is implemented via 
host mmap, so this should just work.
The only time we have a fixed guest address is loading non-pic applications. 
This is known at startup, so can be fixed by setting guest_base appropriately. 
I have partial patches to fix this.
 
> (1) Enable softmmu for userland. This is of course the highest overhead,
>     but will work for all combinations.

This has a significant performance hit, and gets very tricky for things like 
mmaped files.

> (2) Pre-allocate the entire guest address space in the host.  With
>     Linux mmap w/ MAP_NORESERVE or Windows VirtualAlloc w/ MEM_RESERVE
>     and a possibly reduced guest address space this is doesn't seem so bad.

This breaks if the host sets ulimit -v.
 
Paul