From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mog2l-00015O-Q6 for qemu-devel@nongnu.org; Fri, 18 Sep 2009 12:10:43 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mog2g-0000yT-CQ for qemu-devel@nongnu.org; Fri, 18 Sep 2009 12:10:42 -0400 Received: from [199.232.76.173] (port=39389 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mog2g-0000y9-2Q for qemu-devel@nongnu.org; Fri, 18 Sep 2009 12:10:38 -0400 Received: from mail2.shareable.org ([80.68.89.115]:36637) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mog2f-0001l3-Mo for qemu-devel@nongnu.org; Fri, 18 Sep 2009 12:10:37 -0400 Date: Fri, 18 Sep 2009 17:10:35 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [RFC][PATCH] File-backed memory maps Message-ID: <20090918161035.GA9059@shareable.org> References: <1253275896.11717.239.camel@localhost.localdomain> <20090918135906.GB1631@shareable.org> <1253286348.11717.296.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1253286348.11717.296.camel@localhost.localdomain> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Nathan Baum Cc: qemu-devel@nongnu.org Nathan Baum wrote: > > 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. I missed out something important: Not only does the writing process have to clean it's cache (write dirty cachelines); the reading process has to invalidate it's cache too. At the system call level, that means the reading process must call msync(). Until it does that, it may still see some of the data change, but it's not guaranteed to see all the changes. If the writer's copying from QEMU's VRAM to a copy, during that copy, the reading process will see something uncertain; probably not very useful for a VNC server. They would need to coordinate this. Not sure if that buys anything over whatever KVM has to do already :-) RDP server add-ons etc. are a good idea, imho, but perhaps can be implemented as a shared library loaded into qemu? -- Jamie