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

[Marc Zyngier]

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