From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NyvYz-0008CZ-Hb for qemu-devel@nongnu.org; Mon, 05 Apr 2010 19:18:37 -0400 Received: from [140.186.70.92] (port=48008 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NyvYx-00087p-Mb for qemu-devel@nongnu.org; Mon, 05 Apr 2010 19:18:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NyvYv-00018h-Sk for qemu-devel@nongnu.org; Mon, 05 Apr 2010 19:18:35 -0400 Received: from hall.aurel32.net ([88.191.82.174]:46463) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NyvYu-00017g-Ml for qemu-devel@nongnu.org; Mon, 05 Apr 2010 19:18:33 -0400 Date: Tue, 6 Apr 2010 01:18:21 +0200 From: Aurelien Jarno Subject: Re: [Qemu-devel] [RFC] Host vs Guest memory allocation Message-ID: <20100405231821.GA27894@volta.aurel32.net> References: <4BBA6803.3000008@twiddle.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <4BBA6803.3000008@twiddle.net> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: qemu-devel Developers 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 aurelien@aurel32.net http://www.aurel32.net