From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:51268)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <drjones@redhat.com>) id 1YYJKW-0007U7-3V
	for qemu-devel@nongnu.org; Wed, 18 Mar 2015 15:08:41 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <drjones@redhat.com>) id 1YYJKQ-00048R-Dn
	for qemu-devel@nongnu.org; Wed, 18 Mar 2015 15:08:36 -0400
Received: from mx1.redhat.com ([209.132.183.28]:52373)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <drjones@redhat.com>) id 1YYJKQ-00048N-6J
	for qemu-devel@nongnu.org; Wed, 18 Mar 2015 15:08:30 -0400
From: Andrew Jones <drjones@redhat.com>
Date: Wed, 18 Mar 2015 15:08:20 -0400
Message-Id: <1426705700-2564-1-git-send-email-drjones@redhat.com>
Subject: [Qemu-devel] the arm cache coherency cluster "v2"
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=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

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