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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8FD11C77B7A for ; Fri, 19 May 2023 09:16:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=8F696Hl0LlmoRT8t65L8Uj40aRHOS+mrDkYnYjbvV/4=; b=KOq/E18diT1lbE XIdzWdLocVFUvEWTf5z9j/YYkWU8LBlQJ6za9KWS8YPRwMUvcUeVwqes0bQ10lLpPap6V9mDOMnKU hcSYrJ2dw2PWGve3l6etNscR8XIbX80E6pveCvYNN0QRrACnnpyQBlry5nIHKB/BVWRmXYAQFchjy MV3Qaq1FeWOI9NCgfkONwUlbGXOuDELvNDDwdh30FM2Ibfri/qZ20vIpbbqE+MO+jIZxq7/hd0EpP O+k0TkkUM80aPbSzJiB8pc/6inorT7ELCbwuwwLV0RGd4FZDZz80PBRiKwa/2KqbhBz7cN1rScFeQ /6qydel9/O2A/MSX9M8A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pzwDy-00FgA4-2t; Fri, 19 May 2023 09:16:34 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pzwDw-00Fg9K-0g for linux-arm-kernel@lists.infradead.org; Fri, 19 May 2023 09:16:33 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 978B0615B5; Fri, 19 May 2023 09:16:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EFA0DC433D2; Fri, 19 May 2023 09:16:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1684487791; bh=vp8fyf2m1zfTMc2De/CZpZJng1oQxcLCGX8JG2wc9Z4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=lx9YbqAUrgEKdhnRZTGrgA5c0PnJKn7rqnRye3oWZBmCQN4Y00d1+qeMdG2x/vQzC 7GGd/haFegIoW+DwuZkQFJsMJD7TJIdqY6Ak15rqtvTNKd98kMncSbR4DhYEPRpMq8 kD6zsMiXvzKmL07HhoHIiJZSzGfmyQYJVJcefxUnaFigZmj1m84BGO4L5LGd0gaBoC D6yE6bqTbC1x0BaT7Sy3IWzovx4qbsGUyLhmJxA3p0vy//IO9atMPfHf/kFLUtXxWi 2EUQQYedVmrHYc5RAXoGD0me6hYn4FpV7HdtTkH88Suoy5U4cfSveGeC8ZgTzmN2WQ 3jfXqiJwsAAOg== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1pzwDs-00GNCn-Fn; Fri, 19 May 2023 10:16:28 +0100 Date: Fri, 19 May 2023 10:16:28 +0100 Message-ID: <86bkigllzn.wl-maz@kernel.org> From: Marc Zyngier To: "Jitindar Singh, Suraj" Cc: "jingzhangos@google.com" , "pbonzini@redhat.com" , "reijiw@google.com" , "james.morse@arm.com" , "suzuki.poulose@arm.com" , "kvmarm@lists.linux.dev" , "rananta@google.com" , "linux-arm-kernel@lists.infradead.org" , "kvm@vger.kernel.org" , "tabba@google.com" , "oupton@google.com" , "alexandru.elisei@arm.com" , "will@kernel.org" Subject: Re: [PATCH v8 6/6] KVM: arm64: Refactor writings for PMUVer/CSV2/CSV3 In-Reply-To: <7a4a7d86c851563d5ad631070611918906e92015.camel@amazon.com> References: <20230503171618.2020461-1-jingzhangos@google.com> <20230503171618.2020461-7-jingzhangos@google.com> <7a4a7d86c851563d5ad631070611918906e92015.camel@amazon.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2 (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: 185.219.108.64 X-SA-Exim-Rcpt-To: surajjs@amazon.com, jingzhangos@google.com, pbonzini@redhat.com, reijiw@google.com, james.morse@arm.com, suzuki.poulose@arm.com, kvmarm@lists.linux.dev, rananta@google.com, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, tabba@google.com, oupton@google.com, alexandru.elisei@arm.com, will@kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230519_021632_337014_3F67DB64 X-CRM114-Status: GOOD ( 27.67 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 18 May 2023 22:08:15 +0100, "Jitindar Singh, Suraj" wrote: > > Reading init_cpu_ftr_reg() is hurting my head :p but don't we have > basically 2 cases here? > > 1. We are unaffected by spectre|meltdown i.e. > arm64_get_[spectre|meltdown]_v2_state() will return SPECTRE_UNAFFECTED > and we will set the limit to 1 for the csv[1|2] bit fields in > read_sanitised_id_aa64pfr0_el1() > > or > > 2. We ARE affected by spectre|meltdown in which case > arm64_get_[spectre|meltdown]_v2_state() will be > SPECTRE_VULNERABLE|SPECTRE_MITIGATED in which case > read_sanitised_ftr_reg() will return a value with csv[1|2] set to 0 > essentially setting the limit for either of these bit fields to 0 in > read_sanitised_id_aa64pfr0_el1(). What is "WE"? > > Are we trying to catch the case where csv[1|2] is 0 on the host but we > are unaffected as detected by e.g. cpuid and that cpu happens to > incorrectly not set csv[1|2] in the ID register but we still want to > allow the guest to see those bits as set? > > This isn't really related to the CR as I know this is existing code > which has just been moved around and sorry if I'm missing something > obvious. This code is called from *userspace*, and tries to cope with a VM being restored. So we have 3 (not 2 cases): - both the source and the destination have the same level of CSVx support, and all is great in the world - the source has CSVx==0, while the destination has CSVx=1. All good, as we won't be lying to the guest, and the extra mitigation executed by the guest isn't a functional problem. The guest will still see CSVx=0 after migration. - the source has CSVx=1, while the destination has CSVx=0. This isn't an acceptable situation, and we return an error Is that clearer? M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel