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.hender...@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.
