Re: [PATCH v8 6/6] KVM: arm64: Refactor writings for PMUVer/CSV2/CSV3

From: Marc Zyngier <maz@kernel.org>
To: "Jitindar Singh, Suraj" <surajjs@amazon.com>
Cc: "jingzhangos@google.com" <jingzhangos@google.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"reijiw@google.com" <reijiw@google.com>,
	"james.morse@arm.com" <james.morse@arm.com>,
	"suzuki.poulose@arm.com" <suzuki.poulose@arm.com>,
	"kvmarm@lists.linux.dev" <kvmarm@lists.linux.dev>,
	"rananta@google.com" <rananta@google.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"tabba@google.com" <tabba@google.com>,
	"oupton@google.com" <oupton@google.com>,
	"alexandru.elisei@arm.com" <alexandru.elisei@arm.com>,
	"will@kernel.org" <will@kernel.org>
Subject: Re: [PATCH v8 6/6] KVM: arm64: Refactor writings for PMUVer/CSV2/CSV3
Date: Fri, 19 May 2023 10:16:28 +0100	[thread overview]
Message-ID: <86bkigllzn.wl-maz@kernel.org> (raw)
In-Reply-To: <7a4a7d86c851563d5ad631070611918906e92015.camel@amazon.com>

On Thu, 18 May 2023 22:08:15 +0100,
"Jitindar Singh, Suraj" <surajjs@amazon.com> 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.