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