From mboxrd@z Thu Jan  1 00:00:00 1970
From: Christoffer Dall <christoffer.dall@linaro.org>
Subject: Re: [PATCH 4/4] arm/arm64: KVM: use kernel mapping to perform
 invalidation on page fault
Date: Sun, 11 Jan 2015 18:58:41 +0100
Message-ID: <20150111175841.GI21444@cbox>
References: <54AE811F.4020104@arm.com>
 <CAFEAcA9s9-x+aodi0NgWxx2CjdTf8BRfkMkVKCv5JQV0TaU6EA@mail.gmail.com>
 <54AE9D0F.3060002@arm.com>
 <CAFEAcA_9Dh_SWGy+r3ZY2r+r9T_OH0SiiPQm7pzq6_eGYPcJSA@mail.gmail.com>
 <20150109125036.GS21092@cbox>
 <CAFEAcA_S9331rsYZo8=BDh8MSCzOS_dWkxafYGgJ6-zeOqTrLw@mail.gmail.com>
 <54AFE2C9.3020709@arm.com>
 <CAFEAcA-vi7BAqzrR7UeMSDzvXNrOzs2FuO5sTYC2dv6a62=ykw@mail.gmail.com>
 <20150111123347.GV21092@cbox>
 <CAFEAcA8cYMnotQTs16hcZtcup_A3az68_r2QTwUsG8f9G+gWBA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Marc Zyngier <marc.zyngier@arm.com>,
	kvm-devel <kvm@vger.kernel.org>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>
To: Peter Maydell <peter.maydell@linaro.org>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail-la0-f49.google.com ([209.85.215.49]:36663 "EHLO
	mail-la0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750872AbbAKR6M (ORCPT <rfc822;kvm@vger.kernel.org>);
	Sun, 11 Jan 2015 12:58:12 -0500
Received: by mail-la0-f49.google.com with SMTP id hs14so21089195lab.8
        for <kvm@vger.kernel.org>; Sun, 11 Jan 2015 09:58:11 -0800 (PST)
Content-Disposition: inline
In-Reply-To: <CAFEAcA8cYMnotQTs16hcZtcup_A3az68_r2QTwUsG8f9G+gWBA@mail.gmail.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Sun, Jan 11, 2015 at 05:37:52PM +0000, Peter Maydell wrote:
> On 11 January 2015 at 12:33, Christoffer Dall
> <christoffer.dall@linaro.org> wrote:
> > On Fri, Jan 09, 2015 at 03:28:58PM +0000, Peter Maydell wrote:
> >> But implementations are allowed to hit in the cache even
> >> when the cache is disabled. In particular, setting the guest
> >
> > But how can it hit anything when the icache for the used VMID is
> > guaranteed to be clear (maybe that requires another full icache
> > invalidate for that VMID for PSCI reset)?
> 
> The point is that at the moment we don't do anything to
> guarantee that we've cleared the icache. 

that's not entirely accurate, I assume all of the icache is
invalidated/cleaned at system bring-up time, and every time we re-use a
VMID (when we start a VMID rollover) we invalidate the entire icache.

> (Plus could there be
> stale data in the icache for this physical CPU for this VMID
> because we've run some other vCPU on it? Or does the process
> of rescheduling vCPUs across pCPUs and guest ASID management
> deal with that?)

we don't clear the icache for vCPUs migrating onto other pCPUs but
invalidating the icache on a page fault won't guarantee that either.  Do
we really need to do that?

> 
> You probably want to clear the icache on vcpu (re-)init rather
> than reset, though (no guarantee that userspace is going to
> handle system resets via PSCI).
> 
Yes, good point.

-Christoffer