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