From mboxrd@z Thu Jan  1 00:00:00 1970
From: Christoffer Dall <christoffer.dall@linaro.org>
Subject: Re: [PATCH 2/4] arm/arm64: KVM: Use set/way op trapping to track the
 state of the caches
Date: Fri, 9 Jan 2015 13:12:20 +0100
Message-ID: <20150109121220.GP21092@cbox>
References: <1420718349-24152-1-git-send-email-marc.zyngier@arm.com>
 <1420718349-24152-3-git-send-email-marc.zyngier@arm.com>
 <20150109111944.GO21092@cbox>
 <54AFBDAB.4040604@arm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	Steve Capper <steve.capper@linaro.org>
To: Marc Zyngier <marc.zyngier@arm.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail-la0-f45.google.com ([209.85.215.45]:55081 "EHLO
	mail-la0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752904AbbAIMLz (ORCPT <rfc822;kvm@vger.kernel.org>);
	Fri, 9 Jan 2015 07:11:55 -0500
Received: by mail-la0-f45.google.com with SMTP id gq15so14193328lab.4
        for <kvm@vger.kernel.org>; Fri, 09 Jan 2015 04:11:53 -0800 (PST)
Content-Disposition: inline
In-Reply-To: <54AFBDAB.4040604@arm.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Fri, Jan 09, 2015 at 11:38:19AM +0000, Marc Zyngier wrote:

[...]

> >> @@ -258,12 +272,24 @@ bool access_sctlr(struct kvm_vcpu *vcpu,
> >>                 const struct coproc_params *p,
> >>                 const struct coproc_reg *r)
> >>  {
> >> +     bool was_enabled = vcpu_has_cache_enabled(vcpu);
> >> +     bool now_enabled;
> >> +
> >>       access_vm_reg(vcpu, p, r);
> >>
> >> -     if (vcpu_has_cache_enabled(vcpu)) {     /* MMU+Caches enabled? */
> >> -             vcpu->arch.hcr &= ~HCR_TVM;
> >> +     now_enabled = vcpu_has_cache_enabled(vcpu);
> >> +
> >> +     /*
> >> +      * If switching the MMU+caches on, need to invalidate the caches.
> >> +      * If switching it off, need to clean the caches.
> >> +      * Clean + invalidate does the trick always.
> > 
> > couldn't a clean here then be writing bogus to RAM on an initial boot
> > of the guest?
> 
> It shouldn't. We're supposed to start a VM with a fully invalid cache
> (what's why we call coherent_cache_guest_page). And this is no different
> from what we had before, as an invalidate by set/way was upgraded to
> clean+invalidate.
> 

right, that makes sense.

Thanks,
-Christoffer