From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Brook Subject: Re: [Qemu-devel] Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO Date: Mon, 15 Dec 2008 00:57:08 +0000 Message-ID: <200812150057.10162.paul@codesourcery.com> References: <49456337.4000000@redhat.com> <494591F7.3080002@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , Avi Kivity , Andrea Arcangeli , chrisw@redhat.com, kvm@vger.kernel.org, Gerd Hoffmann To: qemu-devel@nongnu.org Return-path: Received: from mail.codesourcery.com ([65.74.133.4]:59582 "EHLO mail.codesourcery.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750753AbYLOA5M (ORCPT ); Sun, 14 Dec 2008 19:57:12 -0500 In-Reply-To: <494591F7.3080002@codemonkey.ws> Content-Disposition: inline Sender: kvm-owner@vger.kernel.org List-ID: > > That's pointless; cirrus for example has 8MB of mmio while a > > cpu-to-vram blit is in progress, and some random device we'll add > > tomorrow could easily introduce more. Our APIs shouldn't depend on > > properties of emulated hardware, at least as much as possible. > > One way to think of what I'm suggesting, is that if for every > cpu_register_physical_memory call for MMIO, we allocated a buffer, then > whenever map() was called on MMIO, we would return that already > allocated buffer. The overhead is fixed and honestly relatively small. > Much smaller than dma.c proposes. I Wouldn't be surprised if some machines had a large memory mapped IO space. Most of it might not be actively used, but once you start considering 64-bit machines on 32-bit hosts these allocations would become problematic.