On Tue, 23 Jul 2024 08:19:59 +0100, Shaoqin Huang <shahuang@xxxxxxxxxx> wrote: > > Hi guys, > > This is another try to allow userspace to change ID_AA64PFR1_EL1, and we want to > give userspace the ability to control the visible feature set for a VM, which > could be used by userspace in such a way to transparently migrate VMs. I think this looks OK now, thanks for going through the motions and doing the right thing. What is missing is similar handling for 32bit ID registers, but I'm not sure we keen on going down that road -- machines capable of running those are on their way out. This can be done later anyway, should anyone care. > > The patch series have four part: > > The first patch disable those fields which KVM doesn't know how to handle, so > KVM will only expose value 0 of those fields to the guest. > > The second patch check the FEAT_SSBS in guest IDREG instead of the cpu > capability. > > The third patch allow userspace to change ID_AA64PFR1_EL1, it only advertise the > fields known to KVM and leave others unadvertise. > > The fourth patch adds the kselftest to test if userspace can change the > ID_AA64PFR1_EL1. > > Besides, I also noticed there is another patch [1] which try to make the > ID_AA64PFR1_EL1 writable. This patch [1] is try to enable GCS on baremental, and > add GCS support for the guest. What I understand is if we have GCS support on > baremental, it will be clear to how to handle them in KVM. And same for other > fields like NMI, THE, DF2, MTEX.. At that time, they can be > writable. I expect that Broonie would look into this as part of his series. Thanks, M. -- Without deviation from the norm, progress is not possible.
