From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FNEU2-0001rP-Ev for qemu-devel@nongnu.org; Sat, 25 Mar 2006 14:31:34 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FNEU0-0001qb-KU for qemu-devel@nongnu.org; Sat, 25 Mar 2006 14:31:33 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FNEU0-0001qP-DH for qemu-devel@nongnu.org; Sat, 25 Mar 2006 14:31:32 -0500 Received: from [65.74.133.6] (helo=mail.codesourcery.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1FNEV6-0004AG-Qp for qemu-devel@nongnu.org; Sat, 25 Mar 2006 14:32:41 -0500 From: Paul Brook Date: Sat, 25 Mar 2006 19:31:21 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200603251931.22488.paul@codesourcery.com> Subject: [Qemu-devel] Usermode emulation changes Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org I've just committed a relatively large patch to the qemu usermode emulation code. Before the patch the userspace emulation code assumed that host and guest address spaces were the same. The goal of these changes is to remove that assumption. This allows us to do two things: - Offset the guest address space by a constant amount. This is useful if the area of memory used by statically linked guest applications is not available on the host. In particular windows hosts can't map the first 64k of memory, and Arm applications are usually liked with a base address of 0x8000. Windows host support is a whole other patch, but this is a prerequisite. - Use of softmmu with usermode emulation. This makes 64-bit guest on 32-bit host possible. Actually doing this still requires a significant amount of work (e.g most of mmap.c would need rewriting). There are two "safe" ways of accessing guest memory from the syscall code. The tget* and tput* macros read/write a single value, including appropriate byteswapping. Alternatively lock_user (and variants) can be used to obtain a pointer to a contiguous block of guest memory. The user is still responsible for byteswapping the data as necessary. Currently these just bias the value and return the appropriate pointer. However with softmmu the block may need copying to a temporary location if it crosses a page boundary. The interface has been designed to allow this to be implemented efficiently. Paul