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.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?
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~