From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LEvfZ-0003qS-IS for qemu-devel@nongnu.org; Mon, 22 Dec 2008 20:02:45 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LEvfX-0003p7-Io for qemu-devel@nongnu.org; Mon, 22 Dec 2008 20:02:44 -0500 Received: from [199.232.76.173] (port=58682 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LEvfX-0003p4-Ed for qemu-devel@nongnu.org; Mon, 22 Dec 2008 20:02:43 -0500 Received: from mx2.redhat.com ([66.187.237.31]:35046) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LEvfW-0005Mf-GI for qemu-devel@nongnu.org; Mon, 22 Dec 2008 20:02:43 -0500 Date: Tue, 23 Dec 2008 02:02:36 +0100 From: Andrea Arcangeli Subject: Re: [Qemu-devel] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO Message-ID: <20081223010236.GI27662@random.random> References: <4943E6F9.1050001@codemonkey.ws> <20081213165306.GE30537@random.random> <4944251D.8080109@codemonkey.ws> <20081214164751.GF30537@random.random> <49453BF2.9070304@redhat.com> <20081214171558.GH30537@random.random> <494565A1.6030306@redhat.com> <18767.50158.909778.205969@mariner.uk.xensource.com> <494FEE06.3040005@redhat.com> <20081223000336.GB16266@networkno.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081223000336.GB16266@networkno.de> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Thiemo Seufer Cc: chrisw@redhat.com, qemu-devel@nongnu.org, kvm@vger.kernel.org, Gerd Hoffmann On Tue, Dec 23, 2008 at 01:03:36AM +0100, Thiemo Seufer wrote: > Running x86-64 binaries on a (non-x86) 32-bit host is IMHO quite an > obvious application for qemu/tcg. I doubt you need device drivers when only translating bytecode. DMA API discussed here is an API for drivers only AFIK. > Interestingly, Virtualbox just started to support > 64-bit-target-on-32-bit-host. Yes, and KVM supports this already AFIK (without PR and without any dynamic map/unmap operation that doesn't exist today). The issue here is not to run 64bit target on 32bit host, this is about running a 64bit target with >3G (or >4G of ram perhaps on sparc32 that has separate kernel/user address space) of ram on a 32bit host. What we're discussing here is a new feature. It's hard to imagine any not-x86 32bit system, to want to run a >3G ram x86-64 (or any other 64bit) VM. It wouldn't work today, and I'm not particularly interested to make it work in 2009 and later given it's 99.9% more likely that you have a 64bit capable CPU than >4G of ram on your system. The limit isn't the size of the guest physical address space, the limit is the amount of RAM that you want to give to the 64bit guest.