From mboxrd@z Thu Jan  1 00:00:00 1970
From: Christoffer Dall <christoffer.dall@linaro.org>
Subject: Re: [PATCH 3/3] arm, arm64: KVM: handle potential incoherency of
 readonly memslots
Date: Sat, 22 Nov 2014 11:18:35 +0100
Message-ID: <20141122101835.GJ3401@cbox>
References: <1416236333-9378-1-git-send-email-ard.biesheuvel@linaro.org>
 <1416236333-9378-3-git-send-email-ard.biesheuvel@linaro.org>
 <546A146E.1020804@redhat.com>
 <546A1905.6080607@redhat.com>
 <546D288F.1040107@samsung.com>
 <20141121111936.GA1785@cbox>
 <546FEBF3.6030401@samsung.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Laszlo Ersek <lersek@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	kvmarm@lists.cs.columbia.edu, marc.zyngier@arm.com,
	drjones@redhat.com, wei@redhat.com, kvm@vger.kernel.org
To: Mario Smarduch <m.smarduch@samsung.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail-lb0-f170.google.com ([209.85.217.170]:61562 "EHLO
	mail-lb0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750958AbaKVKSI (ORCPT <rfc822;kvm@vger.kernel.org>);
	Sat, 22 Nov 2014 05:18:08 -0500
Received: by mail-lb0-f170.google.com with SMTP id w7so5367375lbi.15
        for <kvm@vger.kernel.org>; Sat, 22 Nov 2014 02:18:05 -0800 (PST)
Content-Disposition: inline
In-Reply-To: <546FEBF3.6030401@samsung.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Fri, Nov 21, 2014 at 05:50:43PM -0800, Mario Smarduch wrote:
> On 11/21/2014 03:19 AM, Christoffer Dall wrote:
> > Hi Mario,
> > 
> > On Wed, Nov 19, 2014 at 03:32:31PM -0800, Mario Smarduch wrote:
> >> Hi Laszlo,
> >>
> >> couple observations.
> >>
> >>      I'm wondering if access from qemu and guest won't
> >> result in mixed memory attributes and if that's acceptable
> >> to the CPU.
> >>
> >> Also is if you update memory from qemu you may break
> >> dirty page logging/migration. Unless there is some other way
> >> you keep track. Of course it may not be applicable in your
> >> case (i.e. flash unused after boot).
> >>
> > I'm not concerned about this particular case; dirty page logging exists
> > so KVM can inform userspace when a page may have been dirtied.  If
> > userspace directly dirties (is that a verb?) a page, 
> I would think so, I rely on software too much :)
> > then it already knows that it needs to migrate that page and 
> > deal with it accordingly.
> > 
> > Or did I miss some more subtle point here
> 
> QEMU has a global migration bitmap for all regions initially set
> dirty, and it's updated over iterations with KVM's dirty bitmap. Once
> dirty pages are migrated bits are cleared. If QEMU updates a
> memory region directly I can't see how it's reflected in  that migration
> bitmap that determines what pages should be migrated as it makes
> it's passes. On x86 if host updates guest memory it marks that
> page dirty.
> 
> But virtio writes to guest memory directly and that appears to
> work just fine. I read that code sometime back, and will need to revisit.
> 
In any case, that's a QEMU implementation issue and nothing the kernel
needs to be concerned with.

-Christoffer