From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LEqjJ-0006Eg-7P for qemu-devel@nongnu.org; Mon, 22 Dec 2008 14:46:17 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LEqjH-0006E0-8a for qemu-devel@nongnu.org; Mon, 22 Dec 2008 14:46:15 -0500 Received: from [199.232.76.173] (port=34769 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LEqjG-0006Dw-Oz for qemu-devel@nongnu.org; Mon, 22 Dec 2008 14:46:14 -0500 Received: from mx2.redhat.com ([66.187.237.31]:35190) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LEqjF-0003Lu-RD for qemu-devel@nongnu.org; Mon, 22 Dec 2008 14:46:14 -0500 Message-ID: <494FEE78.6020006@redhat.com> Date: Mon, 22 Dec 2008 21:46:00 +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: <4942B841.6010900@codemonkey.ws> <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> In-Reply-To: <18767.50158.909778.205969@mariner.uk.xensource.com> 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: qemu-devel@nongnu.org Cc: Andrea Arcangeli , chrisw@redhat.com, Gerd Hoffmann , kvm@vger.kernel.org Ian Jackson wrote: > Avi Kivity writes ("[Qemu-devel] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO"): > >> Newer Xen shouldn't have this problem though; it runs qemu in kernel >> mode in a dedicated 64-bit domain. >> > > I think there is continued value in being able to emulate a guest > whose physical address space exceeds the virtual address space in the > host. The whole assumption that all guest accessible RAM is mapped at > once, contiguously, is I think wrong. > 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 or qemu/kvm support large address spaces is pointless IMO. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.