From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Hoffmann Subject: Re: [Qemu-devel] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO Date: Mon, 05 Jan 2009 11:27:52 +0100 Message-ID: <4961E0A8.5040400@redhat.com> 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> <494FEE78.6020006@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: qemu-devel@nongnu.org, Andrea Arcangeli , chrisw@redhat.com, kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from mx2.redhat.com ([66.187.237.31]:43389 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750917AbZAEK2F (ORCPT ); Mon, 5 Jan 2009 05:28:05 -0500 In-Reply-To: <494FEE78.6020006@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity wrote: > Ian Jackson wrote: >> 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. > > If Xen has a problem with 64-bit hosts, we can try to > accommodate it, Yes, this is the whole point. Flesh out the DMA api in a way that Xen can use it. Large memory guests are only one reason why Xen needs map/unmap. The other one is grant table support. > but to have 32-bit qemu/tcg or qemu/kvm support large > address spaces is pointless IMO. You don't have to support that. I think the DMA api should look like this in the end: struct qemu_dma_ops { map(...); xfer(...); unmap(...); }; The qemu/xen implementation would actually map/unmap. For qemu/tcg and qemu/kvm which has all guest memory permanently mapped map() would be a guest-physical -> host-virtual address translation and unmap() would be a nop (or refcount--). cheers, Gerd From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LJmgo-0002WW-Go for qemu-devel@nongnu.org; Mon, 05 Jan 2009 05:28:06 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LJmgl-0002W0-Sq for qemu-devel@nongnu.org; Mon, 05 Jan 2009 05:28:05 -0500 Received: from [199.232.76.173] (port=42556 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LJmgl-0002Vv-Gi for qemu-devel@nongnu.org; Mon, 05 Jan 2009 05:28:03 -0500 Received: from mx2.redhat.com ([66.187.237.31]:49027) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LJmgl-0007QY-0e for qemu-devel@nongnu.org; Mon, 05 Jan 2009 05:28:03 -0500 Message-ID: <4961E0A8.5040400@redhat.com> Date: Mon, 05 Jan 2009 11:27:52 +0100 From: Gerd Hoffmann 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> <494FEE78.6020006@redhat.com> In-Reply-To: <494FEE78.6020006@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 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: Avi Kivity Cc: Andrea Arcangeli , chrisw@redhat.com, qemu-devel@nongnu.org, kvm@vger.kernel.org Avi Kivity wrote: > Ian Jackson wrote: >> 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. > > If Xen has a problem with 64-bit hosts, we can try to > accommodate it, Yes, this is the whole point. Flesh out the DMA api in a way that Xen can use it. Large memory guests are only one reason why Xen needs map/unmap. The other one is grant table support. > but to have 32-bit qemu/tcg or qemu/kvm support large > address spaces is pointless IMO. You don't have to support that. I think the DMA api should look like this in the end: struct qemu_dma_ops { map(...); xfer(...); unmap(...); }; The qemu/xen implementation would actually map/unmap. For qemu/tcg and qemu/kvm which has all guest memory permanently mapped map() would be a guest-physical -> host-virtual address translation and unmap() would be a nop (or refcount--). cheers, Gerd