From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55486) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYJUE-0004TF-Ju for qemu-devel@nongnu.org; Wed, 18 Mar 2015 15:18:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YYJUA-0008Ol-5J for qemu-devel@nongnu.org; Wed, 18 Mar 2015 15:18:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39106) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYJU9-0008OY-Ue for qemu-devel@nongnu.org; Wed, 18 Mar 2015 15:18:34 -0400 Date: Wed, 18 Mar 2015 20:18:20 +0100 From: Andrew Jones Message-ID: <20150318191819.GB7077@hawk.usersys.redhat.com> References: <1426705700-2564-1-git-send-email-drjones@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1426705700-2564-1-git-send-email-drjones@redhat.com> Subject: Re: [Qemu-devel] the arm cache coherency cluster "v2" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: kvmarm@lists.cs.columbia.edu, qemu-devel@nongnu.org, ard.biesheuvel@linaro.org, christoffer.dall@linaro.org, marc.zyngier@arm.com, peter.maydell@linaro.org, pbonzini@redhat.com Cc: catalin.marinas@arm.com, lersek@redhat.com, agraf@suse.de, m.smarduch@samsung.com On Wed, Mar 18, 2015 at 03:08:20PM -0400, Andrew Jones wrote: > In reply to this message I'll send two series' one for KVM and > one for QEMU. The two series' are their respective component > complements, and attempt to implement cache coherency for arm > guests using emulated devices, where the emulator (qemu) uses > cached memory for the device memory, but the guest uses > uncached - as device memory is generally used. Right now I've > just focused on VGA vram. > > This approach is the "MADV_UNCACHED" type that Paolo suggested. > This type of approach could also be described as "make userspace's > memory access type match the expected access type of the guest", > and Mario has suggested using a memory driver, which could have > the same result. > > The coming series' is inspired by both Paolo's and Mario's > suggestions, but it uses a kvm memslot flag, rather than an > madvise flag, and thus for the memory driver, it's just KVM. > > See the thread > > https://lists.gnu.org/archive/html/qemu-devel/2015-03/msg01254.html > > for some more background. > > Thanks in advance for comments. > > drew I forgot to mention that I've done some light testing with this. It seems to work, and without (to eye) noticeable performance degradation. Thanks, drew