qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Aurelien Jarno
Subject: Re: [Qemu-devel] [RFC] Host vs Guest memory allocation
Date: Tue, 6 Apr 2010 01:18:21 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

On Mon, Apr 05, 2010 at 03:45:23PM -0700, Richard Henderson wrote:
> 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.
> 
> (1) Enable softmmu for userland. This is of course the highest overhead,
>     but will work for all combinations.
> 

This option would solve a lot of problems and simplify a lot of code:
unaligned access on hosts requiring strict alignements, different page 
size between host and guest, self-modifying code, 64-bit user land on 
32-bit host, etc... That's what currently comes to my mind, but that 
would solve a lot more problems.

It will clearly have a high overhead, but it might be interesting to
quantify it, to see if we should continue to add tons of code/workaround
to linux-user instead of switching to softmmu for userland. It could
also be optimized, for example by increasing the TLB size compared to 
system mode, and doing TLB preallocation on mmap calls.

IOW this is my favorite option ;-)

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
address@hidden                 http://www.aurel32.net




reply via email to

[Prev in Thread] Current Thread [Next in Thread]