> On 15 Oct 2026, at 6:31 PM, Eric Auger <[email protected]> wrote:
>
> !-------------------------------------------------------------------|
> CAUTION: External Email
>
> |-------------------------------------------------------------------!
>
> Hi Khushit,
>
> On 9/21/26 2:32 PM, Khushit Shah wrote:
>> As named CPU models define their feature set explicitly, their SVE
>> vector lengths and PAuth fields must not be derived from the host.
>>
>> When SVE is enabled without an sve<N> setting, require the named model
>> to specify its supported vector lengths rather than inheriting them from
>> the host.
>>
>> Named models set PAuth ID register fields directly through SYSREG_
>> properties. Preserve these values in PAuth finalization.
>>
>> Signed-off-by: Khushit Shah <[email protected]>
>> ---
>> target/arm/cpu64.c | 33 +++++++++++++++++++++++++++++++++
>> 1 file changed, 33 insertions(+)
>>
>> diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
>> index 7487b48cc9..a0114b0fa2 100644
>> --- a/target/arm/cpu64.c
>> +++ b/target/arm/cpu64.c
>> @@ -38,6 +38,7 @@
>> #include "internals.h"
>> #include "cpu-features.h"
>> #include "cpu-idregs.h"
>> +#include "cpu-models.h"
>> #include "trace.h"
>>
>> /* convert between <register>_IDX and SYS_<register> */
>> @@ -134,6 +135,21 @@ void aarch64_cpu_sve_finalize(ARMCPU *cpu, Error **errp)
>> return;
>> }
>>
>> +#ifndef CONFIG_USER_ONLY
> I don't get why do you need that #ifndef?
Hi Eric,
Yeah, thanks, removed.
>> + /*
>> + * If SVE is enabled but no vector lengths are specified, we must
>> not
>> + * default to the host's supported lengths for named CPU models.
>> + */
>> + {
>> + ARMCPUClass *acc = ARM_CPU_GET_CLASS(cpu);
>> + if (acc->info && arm_find_model(acc->info->name)) {
>> + error_setg(errp,
>> + "Named CPU models with SVE must set vector
>> lengths");
>> + return;
>> + }
>> + }
>> +#endif
>> +
>> if (kvm_enabled()) {
>> /* Disabling a supported length disables all larger lengths. */
>> tmp = vq_init & vq_supported;
>> @@ -556,6 +572,23 @@ void aarch64_cpu_pauth_finalize(ARMCPU *cpu, Error
>> **errp)
>> ARMISARegisters *isar = &cpu->isar;
>> uint64_t isar1, isar2;
>>
>> +#ifndef CONFIG_USER_ONLY
>> + /*
>> + * For named CPU models the model props write the authoritative
>> + * APA/API/APA3/GPA/GPI/GPA3 values directly into cpu->isar through
> all those fields ar not KVM writable currently.
Correct, but here we are letting the named model build it’s ID register view.
Later in writeback (based on v9), we error out if the KVM’s and model’s ID
register view disagree.
>> + * SYSREG_ properties, so do not override them here. Since other code
>> + * relies on cpu->prop_pauth, mirror the resulting pauth state into
>> + * cpu->prop_pauth.
>> + */
>> + {
>> + ARMCPUClass *acc = ARM_CPU_GET_CLASS(cpu);
>> + if (acc->info && arm_find_model(acc->info->name)) {
>> + cpu->prop_pauth = cpu_isar_feature(aa64_pauth, cpu);
>> + return;
>> + }
>> + }
>> +#endif
> If I understand correctly all the isar1/isar2 manipulations afterwards
> only affect TCG.
> In KVM mode, although isar1/isar2 fields are reset afterwards this does
> not impact the guest view so most probably the isa1/2 reset + finale
> update could be moved to the !hw_accel block and you put that addition
> in the hwaccel_enabled() block, or am i wrong?
For the current patch series, the QEMU idregs[] directly affects KVM’s
idregs. So, if pauth is disabled, KVM will erase _APA/_GPA, during
writeback check that KVM’s _APA/_GPA matches QEMU’s values. So, if we
do not reset these here, then the condition will fail.
I need to look at v10 in detail to understand what will happen there.
Thanks,
Khushit
> Thanks
>
> Eric
>> +
>> /*
>> * These properties enable or disable Pauth as a whole, or change
>> * the pauth algorithm, but do not change the set of features that
>
