KVM sysreg ids for FEAT_SYSREG128

KVM sysreg ids for FEAT_SYSREG128

[Richard Henderson]

Hiya,

QEMU (ab)uses the kvm encoding of system register ids in the migration stream.  As we 
implement support for FEAT_D128, it would be good to agree on an encoding for the 128-bit 
registers so that we can avoid complications with migration later.

I don't think this is terribly complicated.  Simply adjust the value in the 
KVM_REG_SIZE_MASK field from U64 to U128.  E.g.

PAR_EL1 (64-bit)	(__ARM64_SYS_REG(3, 0, 7, 4, 0) | KVM_REG_SIZE_U64)
PAR_EL1 (128-bit)	(__ARM64_SYS_REG(3, 0, 7, 4, 0) | KVM_REG_SIZE_U128)

This will currently be cleanly rejected by index_to_params, resulting in ENOENT for the 
ioctl.  When KVM grows support for D128 guests, kvm_sys_reg_{get,set}_user can select the 
read/write code path based on reg->id & KVM_REG_SIZE_MASK.

Comments?


r~

Re: KVM sysreg ids for FEAT_SYSREG128

[Marc Zyngier]

Hi Richard,

Thanks for bringing this up. FEAT_D128 is not on anyone's radar on the
KVM side (I really don't fancy having to write another set of page
table walkers), but it doesn't hurt to be prepared.

On Thu, 14 Aug 2025 00:27:25 +0100,
Richard Henderson <richard.henderson@linaro.org> wrote:
> 
> Hiya,
> 
> QEMU (ab)uses the kvm encoding of system register ids in the migration
> stream.  As we implement support for FEAT_D128, it would be good to
> agree on an encoding for the 128-bit registers so that we can avoid
> complications with migration later.
> 
> I don't think this is terribly complicated.  Simply adjust the value
> in the KVM_REG_SIZE_MASK field from U64 to U128.  E.g.
> 
> PAR_EL1 (64-bit)	(__ARM64_SYS_REG(3, 0, 7, 4, 0) | KVM_REG_SIZE_U64)
> PAR_EL1 (128-bit)	(__ARM64_SYS_REG(3, 0, 7, 4, 0) | KVM_REG_SIZE_U128)
> 
> This will currently be cleanly rejected by index_to_params, resulting
> in ENOENT for the ioctl.  When KVM grows support for D128 guests,
> kvm_sys_reg_{get,set}_user can select the read/write code path based
> on reg->id & KVM_REG_SIZE_MASK.
> 
> Comments?

The encoding of the register, as described above, is absolutely fine.

But since you brought the subject, I'd like to align on a bit more
than the encoding.

The way I see imagine it after two cups of coffee (which clearly isn't
enough) is to have a feature bit provided at VM creation time,
enabling D128 support, HW support allowing.

At that point, querying the list of supported sysregs would report the
128bit versions of TTBR{0,1}_EL{1,2}, VTTBR_EL2, and PAR_EL1 (ignoring
things we are unlikely to ever support, such as FEAT_THE). The 64bit
versions of these registers would not be reported.

Does that align with what QEMU would do internally?

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

Re: KVM sysreg ids for FEAT_SYSREG128

[Richard Henderson]

On 8/14/25 18:11, Marc Zyngier wrote:
> Hi Richard,
> 
> Thanks for bringing this up. FEAT_D128 is not on anyone's radar on the
> KVM side (I really don't fancy having to write another set of page
> table walkers), but it doesn't hurt to be prepared.
> 
> On Thu, 14 Aug 2025 00:27:25 +0100,
> Richard Henderson <richard.henderson@linaro.org> wrote:
>>
>> Hiya,
>>
>> QEMU (ab)uses the kvm encoding of system register ids in the migration
>> stream.  As we implement support for FEAT_D128, it would be good to
>> agree on an encoding for the 128-bit registers so that we can avoid
>> complications with migration later.
>>
>> I don't think this is terribly complicated.  Simply adjust the value
>> in the KVM_REG_SIZE_MASK field from U64 to U128.  E.g.
>>
>> PAR_EL1 (64-bit)	(__ARM64_SYS_REG(3, 0, 7, 4, 0) | KVM_REG_SIZE_U64)
>> PAR_EL1 (128-bit)	(__ARM64_SYS_REG(3, 0, 7, 4, 0) | KVM_REG_SIZE_U128)
>>
>> This will currently be cleanly rejected by index_to_params, resulting
>> in ENOENT for the ioctl.  When KVM grows support for D128 guests,
>> kvm_sys_reg_{get,set}_user can select the read/write code path based
>> on reg->id & KVM_REG_SIZE_MASK.
>>
>> Comments?
> 
> The encoding of the register, as described above, is absolutely fine.
> 
> But since you brought the subject, I'd like to align on a bit more
> than the encoding.
> 
> The way I see imagine it after two cups of coffee (which clearly isn't
> enough) is to have a feature bit provided at VM creation time,
> enabling D128 support, HW support allowing.
> 
> At that point, querying the list of supported sysregs would report the
> 128bit versions of TTBR{0,1}_EL{1,2}, VTTBR_EL2, and PAR_EL1 (ignoring
> things we are unlikely to ever support, such as FEAT_THE). The 64bit
> versions of these registers would not be reported.
> 
> Does that align with what QEMU would do internally?

Yes.

After selecting the feature set for the cpu, we register the system registers that 
correspond to each feature.  During registration, we select the size of each register 
(more specifically, the canonical definition is maximal, and 128-bit registers are 
squashed back down to a 64-bit registers when FEAT_SYSREG128 is not enabled).

We always require the same cpu model during migration, and the choice of register size is 
tied to the cpu model, so there shouldn't be any migration issues.  With -cpu max, we 
explicitly don't support migration between qemu versions.


r~