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: Thu, 15 Jan 2015 14:00:58 +0100 Message-ID: <20150115130058.GY26222@cbox> References: <20150111175841.GI21444@cbox> <20150111183828.GA3868@cbox> <54B39AC6.7000807@arm.com> <20150112201009.GC26222@cbox> <54B503CE.4000809@arm.com> <20150113120458.GE26222@cbox> <20150113133516.GF26222@cbox> <20150115120020.GD16217@leverpostej> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Peter Maydell , "kvmarm@lists.cs.columbia.edu" , kvm-devel To: Mark Rutland Return-path: Received: from mail-lb0-f182.google.com ([209.85.217.182]:49976 "EHLO mail-lb0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755014AbbAONA5 (ORCPT ); Thu, 15 Jan 2015 08:00:57 -0500 Received: by mail-lb0-f182.google.com with SMTP id u10so13000397lbd.13 for ; Thu, 15 Jan 2015 05:00:55 -0800 (PST) Content-Disposition: inline In-Reply-To: <20150115120020.GD16217@leverpostej> Sender: kvm-owner@vger.kernel.org List-ID: Hi Mark, On Thu, Jan 15, 2015 at 12:00:20PM +0000, Mark Rutland wrote: > On Tue, Jan 13, 2015 at 01:35:16PM +0000, Christoffer Dall wrote: > > On Tue, Jan 13, 2015 at 12:12:41PM +0000, Peter Maydell wrote: > > > On 13 January 2015 at 12:04, Christoffer Dall > > > wrote: > > > > Additionally, I haven't been able to think of a reasonable guest > > > > scenario where this breaks. Once the guest turns on its MMU it should > > > > deal with the necessary icache invalidation itself (I think), so we're > > > > really talking about situations where the stage-1 MMU is off, and I > > > > gather that mostly you'll be seeing a single core doing any heavy > > > > lifting and then secondary cores basically coming up, only seeing valid > > > > entries in the icache, and doing the necessary invalidat+turn on mmu > > > > stuff. > > > > > > The trouble with that is that as the secondary comes up, before it > > > turns on its icache its VA->PA mapping is the identity map; whereas > > > the primary vCPU's VA->PA mapping is "whatever the guest kernel's > > > usual mapping is". If the kernel has some mapping other than identity > > > for the VA which is wherever the secondary-CPU-startup-to-MMU-enable > > > code lives (which seems quite likely), then you have potential problems. > > > > > Wouldn't a guest (and I believe Linux does this) reserve ASID 0 for > > additional cores and use ASID 1+++ for itself? > > Not on arm since 52af9c6cd863fe37 (ARM: 6943/1: mm: use TTBR1 instead of > reserved context ID) and 45b95235b0ac86ce (ARM: 6944/1: mm: allow ASID 0 > to be allocated to tasks). The swapper_pg_dir uses global mappings since > d427958a46af24f7 (ARM: 6942/1: mm: make TTBR1 always point to > swapper_pg_dir on ARMv6/7). thanks for the pointer, been a while since I looked at that code. > > Similarly on arm64 the swapper_pg_dir and idmap_pg_dir use global > mappings and we don't reserve any ASIDs for use by the kernel. > Do you happen to know which ASIDs are matched in the icache when the MMU is off? -Christoffer