From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LFB6n-0007I5-4N for qemu-devel@nongnu.org; Tue, 23 Dec 2008 12:31:53 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LFB6k-0007Hl-QX for qemu-devel@nongnu.org; Tue, 23 Dec 2008 12:31:51 -0500 Received: from [199.232.76.173] (port=55547 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LFB6k-0007Hh-Fu for qemu-devel@nongnu.org; Tue, 23 Dec 2008 12:31:50 -0500 Received: from mx2.redhat.com ([66.187.237.31]:45792) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LFB6k-0001VU-11 for qemu-devel@nongnu.org; Tue, 23 Dec 2008 12:31:50 -0500 Message-ID: <4951207D.9060405@redhat.com> Date: Tue, 23 Dec 2008 19:31:41 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO References: <20081213143944.GD30537@random.random> <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> In-Reply-To: <20081223000336.GB16266@networkno.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Andrea Arcangeli , chrisw@redhat.com, qemu-devel@nongnu.org, kvm@vger.kernel.org, Gerd Hoffmann Thiemo Seufer wrote: >> I agree that we shouldn't expect memory to be contiguous, in order to >> properly support hotplug. But I see zero value in trying to support >> large memory configurations on 32-bit in 2008. This is what 64-bit >> systems are for! If Xen has a problem with 64-bit hosts, we can try to >> accommodate it, but to have 32-bit qemu/tcg >> > > Running x86-64 binaries on a (non-x86) 32-bit host is IMHO quite an > obvious application for qemu/tcg. > I agree. I don't think running guests with >2GB of RAM on 32-bit hosts is a good idea, though. Instruction set, physical address space width, and actual maximum memory size supported are very different things. I'm sure you don't want qemu to swap memory in and out of its address space (which is what Xen does). >> or qemu/kvm support large address spaces is pointless IMO. >> > > Interestingly, Virtualbox just started to support > 64-bit-target-on-32-bit-host. > That makes sense on Windows, where 32-bit hosts still have an advantage over 64-bit. But again, that's very different from supporting a large address space. Want 64-bit guests? sure, qemu/tcg can handle it, as well as qemu/kvm (on a 64-bit host). Want lots of memory for your CAD application/openoffice docs/qemu guests? Use a 64-bit host. -- error compiling committee.c: too many arguments to function