From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55551 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q5PaB-0001Kl-9w for qemu-devel@nongnu.org; Thu, 31 Mar 2011 17:39:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q5PaA-0004Ed-E3 for qemu-devel@nongnu.org; Thu, 31 Mar 2011 17:39:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:20843) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q5PaA-0004EU-45 for qemu-devel@nongnu.org; Thu, 31 Mar 2011 17:39:10 -0400 Date: Thu, 31 Mar 2011 23:38:49 +0200 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] [PATCH RFC] vga: flag vga ram for notifiers Message-ID: <20110331213849.GB27264@redhat.com> References: <20110331174328.GA25133@redhat.com> <4D94C916.6080709@codemonkey.ws> <20110331184940.GA25688@redhat.com> <4D94CFA0.3030605@codemonkey.ws> <4D94D62E.2060206@codemonkey.ws> <4D94E2A7.80700@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Alex Williamson , qemu-devel@nongnu.org On Thu, Mar 31, 2011 at 10:32:11PM +0100, Peter Maydell wrote: > On 31 March 2011 21:23, Anthony Liguori wrote: > > On 03/31/2011 03:12 PM, Peter Maydell wrote: > >> Well, obviously you need to be able to revoke the permission > >> to use the fastpath pointer to the underlying memory. But you > >> need to be able to do that anyhow, to cover cases where (eg) the > >> guest has just written to some register that remaps the bottom > >> part of the address space so it's ROM rather than RAM, or whatever. > >> It's just a feature your optimisation needs to have. Equally, you > >> don't remap unless you have to, but if the mapping's changed then > >> it's changed... > > > > Right, the trouble now is that there's no way to distinguish between mapping > > where 1) we don't care about them in virtio and 2) they change frequently. > > Aha. Thanks for the explanation. > > > Maybe the right approach here is to just use a virtio specific API and > > register RAM as register_virtio_dma_area(). > > That seems like a clearer API, yes. I think it makes it much more > obvious what it's trying to achieve. > > -- PMM Maybe register_dma_area - its' not 100% virtio specific. -- MST