From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mof0L-0001sn-7N for qemu-devel@nongnu.org; Fri, 18 Sep 2009 11:04:09 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mof0G-0001rK-AD for qemu-devel@nongnu.org; Fri, 18 Sep 2009 11:04:08 -0400 Received: from [199.232.76.173] (port=42639 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mof0G-0001rE-69 for qemu-devel@nongnu.org; Fri, 18 Sep 2009 11:04:04 -0400 Received: from smarthost.c4l.co.uk ([82.197.83.77]:47684) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mof0F-0000Wb-L7 for qemu-devel@nongnu.org; Fri, 18 Sep 2009 11:04:03 -0400 Subject: Re: [Qemu-devel] [RFC][PATCH] File-backed memory maps From: Nathan Baum In-Reply-To: <20090918135906.GB1631@shareable.org> References: <1253275896.11717.239.camel@localhost.localdomain> <20090918135906.GB1631@shareable.org> Content-Type: text/plain Date: Fri, 18 Sep 2009 16:05:48 +0100 Message-Id: <1253286348.11717.296.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: qemu-devel@nongnu.org On Fri, 2009-09-18 at 14:59 +0100, Jamie Lokier wrote: > Nathan Baum wrote: > > makes two files named "prefix.vga" and "prefix.bios" which contain the > > respective memory regions. The maps I've named are 640k, before_4g, > > after_4g, vga, bios and option_rom. > > > > I'm mainly interested in the idea of moving the VNC server into its own > > process. It would listen for connections as usual and then send > > framebuffer updates from the file. Doing that also requires a > > side-channel for communicating graphics mode updates and peripheral > > input between QEMU and the VNC server. (Something like "-mouse > > -keyboard ", perhaps?) > > Are there any cache coherency issues? Hmm. I expect so. I'm not sure what the consequences of this are, or whether cache decoherence itself is the major issue. Even if cache coherence is guaranteed, the contents of VRAM can change whilst the "display server" is processing it, likely with undesirable results, unless it were double buffered. If, upon a dpy_update, VRAM was blitted to "prefix.vga" which we then msync(), a display server could be sure of always seeing its copy of the VRAM in a consistent state. It seems to me that might as well be implemented as the new display type I mentioned later in my post, rather than a double-buffered version of this more general memory sharing feature (who wants to be blitting 4GB of RAM around anyway?). I assume that with that arrangement, cache decoherence wouldn't be an issue on any platform. I'm not sure that would leave this patch with much to do. :-) > On architectures other than x86, sometimes data written by one process > is not visible to another process mapping the same file, until the > writing process flushes it's cache for those pages. Whether that's > necessary depends on the address that pages are mapped to. Afaik, > normally Linux chooses an address where this issue is avoided, but if > you specify it with MAP_FIXED (or whatever KVM does to map pages), > then there's cache coherency to deal with. > -- Jamie