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

On Thu, 18 May 2023 22:08:15 +0100,
"Jitindar Singh, Suraj" [off-list ref] 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