On Thu, 16 Oct 2025 at 15:01, Eric Auger <[email protected]> wrote: > > Newer kernels may revoke exposure of KVM regs to userspace. This can > happen when one notices that some registers were unconditionnally > exposed whether they shall be conditionnally exposed for example. > > An example of such situation is: TCR2_EL1, PIRE0_EL1, PIR_EL1. > Associated kernel commits were: > 0fcb4eea5345 KVM: arm64: Hide TCR2_EL1 from userspace when disabled for > guests > a68cddbe47ef KVM: arm64: Hide S1PIE registers from userspace when disabled > for guests > > Those commits were actual fixes but the cons is that is breaks forward > migration on some HW. Indeed when migrating from an old kernel that > does not feature those commits to a more recent one, destination > qemu detects there are more KVM regs in the input migration stream than > exposed by the destination host and the migration fails with: > "failed to load cpu:cpreg_vmstate_array_len" > > This patchs adds the capability to defined an array of enforced > register indexes that teaches QEMU that some registers must exist. > If they are not exposed by KVM qemu fakes their presence in the > preload phase by adjusting the size of the cpreg_vmstate arrays. > On postload we make sure to ignore them when analyzing potential > mismatch between registers. The actual cpreg array is never altered > meaning those registers are never accessed nor saved.
It's not really clear to me what we mean by "faking" these registers. It's definitely not the case that we want QEMU to think these registers must exist -- they really don't, and for migration from a new kernel to a new kernel we shouldn't include these registers. We just would like to be able to ignore them in the input migration stream so we can handle the inbound migration from an older kernel. thanks -- PMM
