From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6012FCA9EC0 for ; Mon, 28 Oct 2019 13:45:56 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id D96BC20862 for ; Mon, 28 Oct 2019 13:45:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D96BC20862 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 443934AC65; Mon, 28 Oct 2019 09:45:55 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zB+f7fA4uSNJ; Mon, 28 Oct 2019 09:45:54 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 30D6C4A53F; Mon, 28 Oct 2019 09:45:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 0EAFD4A417 for ; Mon, 28 Oct 2019 09:45:53 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKtUs-otPkGM for ; Mon, 28 Oct 2019 09:45:52 -0400 (EDT) Received: from inca-roads.misterjones.org (inca-roads.misterjones.org [213.251.177.50]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id DE4364A389 for ; Mon, 28 Oct 2019 09:45:51 -0400 (EDT) Received: from [91.217.168.176] (helo=big-swifty.misterjones.org) by cheepnis.misterjones.org with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (Exim 4.80) (envelope-from ) id 1iP5LB-00056r-Lf; Mon, 28 Oct 2019 14:45:49 +0100 Date: Mon, 28 Oct 2019 13:45:49 +0000 Message-ID: <86tv7tx9te.wl-maz@kernel.org> From: Marc Zyngier To: Christoffer Dall Subject: Re: [PATCH v2] KVM: arm64: Don't set HCR_EL2.TVM when S2FWB is supported In-Reply-To: <20191028130541.30536-1-christoffer.dall@arm.com> References: <20191028130541.30536-1-christoffer.dall@arm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 EasyPG/1.0.0 Emacs/26 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 91.217.168.176 X-SA-Exim-Rcpt-To: christoffer.dall@arm.com, kvmarm@lists.cs.columbia.edu, james.morse@arm.com, julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com, linux-arm-kernel@lists.infradead.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on cheepnis.misterjones.org); SAEximRunCond expanded to false Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Mon, 28 Oct 2019 13:05:41 +0000, Christoffer Dall wrote: > > On CPUs that support S2FWB (Armv8.4+), KVM configures the stage 2 page > tables to override the memory attributes of memory accesses, regardless > of the stage 1 page table configurations, and also when the stage 1 MMU > is turned off. This results in all memory accesses to RAM being > cacheable, including during early boot of the guest. > > On CPUs without this feature, memory accesses were non-cacheable during > boot until the guest turned on the stage 1 MMU, and we had to detect > when the guest turned on the MMU, such that we could invalidate all cache > entries and ensure a consistent view of memory with the MMU turned on. > When the guest turned on the caches, we would call stage2_flush_vm() > from kvm_toggle_cache(). > > However, stage2_flush_vm() walks all the stage 2 tables, and calls > __kvm_flush-dcache_pte, which on a system with S2FWD does ... absolutely s/FWD/FWB/ > nothing. > > We can avoid that whole song and dance, and simply not set TVM when > creating a VM on a system that has S2FWB. > > Signed-off-by: Christoffer Dall > Reviewed-by: Mark Rutland Apart from the nit above, and Mark's other remark, it looks good to me. I'll fix them up when applying the patch. Thanks, M. -- Jazz is not dead, it just smells funny. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm