From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoffer Dall Subject: Re: [PATCH 4/4] arm/arm64: KVM: use kernel mapping to perform invalidation on page fault Date: Sun, 11 Jan 2015 19:38:28 +0100 Message-ID: <20150111183828.GA3868@cbox> References: <54AE9D0F.3060002@arm.com> <20150109125036.GS21092@cbox> <54AFE2C9.3020709@arm.com> <20150111123347.GV21092@cbox> <20150111175841.GI21444@cbox> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Marc Zyngier , kvm-devel , "kvmarm@lists.cs.columbia.edu" To: Peter Maydell Return-path: Received: from mail-lb0-f175.google.com ([209.85.217.175]:38069 "EHLO mail-lb0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751044AbbAKSic (ORCPT ); Sun, 11 Jan 2015 13:38:32 -0500 Received: by mail-lb0-f175.google.com with SMTP id z11so14744521lbi.6 for ; Sun, 11 Jan 2015 10:38:31 -0800 (PST) Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Sun, Jan 11, 2015 at 06:27:35PM +0000, Peter Maydell wrote: > On 11 January 2015 at 17:58, Christoffer Dall > wrote: > > On Sun, Jan 11, 2015 at 05:37:52PM +0000, Peter Maydell wrote: > >> On 11 January 2015 at 12:33, Christoffer Dall > >> 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. > > Right, but that doesn't catch the VM reset case, which is the > one we're talking about. > ok, so that's what you meant by warm reset, I see. Then I would think we should add that single invalidate on vcpu init rather than flushing the icache on every page fault? > >> (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? > > I don't think we do, but I haven't thought through exactly > why we don't yet :-) > So once you start a secondary vCPU that one can then hit in the icache from what the primary vCPU put there which I guess is different behavior from a physical secondary core coming out of reset with the MMU off and never hitting the icache, right? And is this not also a different behavior from a native system once the vCPUs have turned their MMUs on, but we just don't happen to observe it as being a problem? In any case, I don't have a great solution for how to solve this except for always invalidating the icache when we migrate a vCPU to a pCPU, but that's really nasty... -Christoffer