From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc Zyngier Subject: Re: [PATCH 4/4] arm/arm64: KVM: use kernel mapping to perform invalidation on page fault Date: Fri, 09 Jan 2015 17:18:29 +0000 Message-ID: <54B00D65.4060705@arm.com> References: <1420718349-24152-1-git-send-email-marc.zyngier@arm.com> <1420718349-24152-5-git-send-email-marc.zyngier@arm.com> <54AE811F.4020104@arm.com> <54AE9D0F.3060002@arm.com> <20150109125036.GS21092@cbox> <54AFE2C9.3020709@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Christoffer Dall , kvm-devel , "kvmarm@lists.cs.columbia.edu" To: Peter Maydell Return-path: Received: from foss-mx-na.foss.arm.com ([217.140.108.86]:59054 "EHLO foss-mx-na.foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752107AbbAIRSi (ORCPT ); Fri, 9 Jan 2015 12:18:38 -0500 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 09/01/15 15:28, Peter Maydell wrote: > On 9 January 2015 at 14:16, Marc Zyngier wrote: >> On 09/01/15 13:03, Peter Maydell wrote: >>> When we reset a cpu by re-calling KVM_ARM_VCPU_INIT, that doesn't >>> mean we get a new VMID for it, though, does it? I thought that >>> what causes the icache flush to happen for the reset guest is >>> that we unmap all of stage 2 and then fault it back in, via >>> this code. That works for PIPT (we flush the range) and for >>> VIPT (we do a full icache flush), but at the moment for VIVT >>> ASID tagged we assume we can do nothing, and I don't think that's >>> right for this case (though it is right for "faulted because >>> page was swapped out" and OK for "page was written by DMA"). >> >> When we reset the guest, we also turn both its Icache off. Before >> turning it back on, the guest has to invalidate it (the ARM ARM doesn't >> seem to define the state of the cache out of reset). > > But implementations are allowed to hit in the cache even > when the cache is disabled. In particular, setting the guest > SCTLR_EL1.I to 0 means "iside accesses are Normal Noncacheable > for stage 1 attributes" and (v8 ARM ARM D3.4.6) these can > be held in the instruction cache. So the guest is required > to do an icache-invalidate for any instructions that it writes > *itself* (or DMAs in) even with the icache off. But it cannot > possibly do so for its own initial startup code, and it must > be the job of KVM to do that for it. (You can think of this as > "the VCPU provided by KVM always invalidates the icache on reset > and does not require an impdef magic cache-init routine as > described by D3.4.4" if you like.) Right. I think I finally see your point. We've been safe so far that no ASID-tagged VIVT icache platform is virtualisation capable, AFAIK. Probably best to just nuke the icache always for non-PIPT caches, then. I'll fold that in when I respin the series. Thanks, M. -- Jazz is not dead. It just smells funny...