[PATCH v3 0/4] KVM: arm64: writable MIDR/REVIDR

Sebastian Ott posted 4 patches 10 months ago
arch/arm64/include/asm/kvm_host.h             |   9 ++
arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h    |   5 +-
arch/arm64/kvm/hyp/nvhe/sysreg-sr.c           |  10 +-
arch/arm64/kvm/hyp/vhe/sysreg-sr.c            |  28 ++--
arch/arm64/kvm/sys_regs.c                     | 137 +++++++-----------
.../testing/selftests/kvm/arm64/set_id_regs.c |  32 +++-
6 files changed, 108 insertions(+), 113 deletions(-)
[PATCH v3 0/4] KVM: arm64: writable MIDR/REVIDR
Posted by Sebastian Ott 10 months ago
Based on prior discussion [1] this series allows VMMs to change
MIDR/REVIDR to enable migration between machines that differ in
these registers. Since these are used for errata handling the
errata management series [2] is a prerequisite for this one.

changes for V3:
* handle VPIDR_EL2 as part of vcpu ctxt - thanks Oliver!

changes for V2:
* let the guest actually observe the changed MIDR_EL1 value
* extra .set_user function
* added selftest

[1] https://lore.kernel.org/kvmarm/20250124151732.6072-1-shameerali.kolothum.thodi@huawei.com/T/#mb855bc51714095a164a7b26bb8bead1606e4b753
[2] https://lore.kernel.org/kvmarm/20250205132222.55816-1-shameerali.kolothum.thodi@huawei.com/T/

Sebastian Ott (4):
  KVM: arm64: Allow userspace to change MIDR_EL1
  KVM: arm64: Allow userspace to change REVIDR_EL1
  KVM: arm64: Allow userspace to change AIDR_EL1
  KVM: selftests: arm64: Test writes to MIDR,REVIDR,AIDR

 arch/arm64/include/asm/kvm_host.h             |   9 ++
 arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h    |   5 +-
 arch/arm64/kvm/hyp/nvhe/sysreg-sr.c           |  10 +-
 arch/arm64/kvm/hyp/vhe/sysreg-sr.c            |  28 ++--
 arch/arm64/kvm/sys_regs.c                     | 137 +++++++-----------
 .../testing/selftests/kvm/arm64/set_id_regs.c |  32 +++-
 6 files changed, 108 insertions(+), 113 deletions(-)

-- 
2.42.0
Re: [PATCH v3 0/4] KVM: arm64: writable MIDR/REVIDR
Posted by Oliver Upton 9 months, 3 weeks ago
Hi Sebastian,

On Tue, Feb 18, 2025 at 05:34:39PM +0100, Sebastian Ott wrote:
> Based on prior discussion [1] this series allows VMMs to change
> MIDR/REVIDR to enable migration between machines that differ in
> these registers. Since these are used for errata handling the
> errata management series [2] is a prerequisite for this one.
> 
> changes for V3:
> * handle VPIDR_EL2 as part of vcpu ctxt - thanks Oliver!

Thanks for respinning. While your changes are looking good, as I got
ready to apply this series I wound up peeling the onion a bit further
and have a few more concerns:

 - Current KVM allows guests to read SMIDR_EL1 despite the fact that we
   do not support SME (this is part of TID1 traps)

 - The "invariant" values that KVM presents to userspace originate from
   the boot CPU, not the CPU that resets the ID registers for a VM

 - A VMM that wants to present big-little can do so on current KVM by
   affining vCPUs, but cannot with this series

All of this is to say, I think your series is going to collide with
the pre-existing pile of crap we have. I'm going to pick up these
changes and rework them so we can send a fix for #1 to stable trees and
(hopefully) avoid breaking the old "invariant" behavior.

I'll post what I have as soon as I test it, hopefully we can get this
shaped up for 6.15.

Thanks,
Oliver
Re: [PATCH v3 0/4] KVM: arm64: writable MIDR/REVIDR
Posted by Sebastian Ott 9 months, 3 weeks ago
Hi Oliver,

On Mon, 24 Feb 2025, Oliver Upton wrote:
> On Tue, Feb 18, 2025 at 05:34:39PM +0100, Sebastian Ott wrote:
>> Based on prior discussion [1] this series allows VMMs to change
>> MIDR/REVIDR to enable migration between machines that differ in
>> these registers. Since these are used for errata handling the
>> errata management series [2] is a prerequisite for this one.
>>
>> changes for V3:
>> * handle VPIDR_EL2 as part of vcpu ctxt - thanks Oliver!
>
> Thanks for respinning. While your changes are looking good, as I got
> ready to apply this series I wound up peeling the onion a bit further
> and have a few more concerns:
>
> - Current KVM allows guests to read SMIDR_EL1 despite the fact that we
>   do not support SME (this is part of TID1 traps)
>
> - The "invariant" values that KVM presents to userspace originate from
>   the boot CPU, not the CPU that resets the ID registers for a VM
>
> - A VMM that wants to present big-little can do so on current KVM by
>   affining vCPUs, but cannot with this series
>
> All of this is to say, I think your series is going to collide with
> the pre-existing pile of crap we have. I'm going to pick up these
> changes and rework them so we can send a fix for #1 to stable trees and
> (hopefully) avoid breaking the old "invariant" behavior.
>
> I'll post what I have as soon as I test it, hopefully we can get this
> shaped up for 6.15.

Sry, for the additional work I've caused. I gave what you have in next a
spin and it looks good so far.
Thank you very much!

Sebastian
Re: [PATCH v3 0/4] KVM: arm64: writable MIDR/REVIDR
Posted by Oliver Upton 9 months, 3 weeks ago
On Wed, Feb 26, 2025 at 05:47:53PM +0100, Sebastian Ott wrote:
> On Mon, 24 Feb 2025, Oliver Upton wrote:
> > On Tue, Feb 18, 2025 at 05:34:39PM +0100, Sebastian Ott wrote:
> > > Based on prior discussion [1] this series allows VMMs to change
> > > MIDR/REVIDR to enable migration between machines that differ in
> > > these registers. Since these are used for errata handling the
> > > errata management series [2] is a prerequisite for this one.
> > > 
> > > changes for V3:
> > > * handle VPIDR_EL2 as part of vcpu ctxt - thanks Oliver!
> > 
> > Thanks for respinning. While your changes are looking good, as I got
> > ready to apply this series I wound up peeling the onion a bit further
> > and have a few more concerns:
> > 
> > - Current KVM allows guests to read SMIDR_EL1 despite the fact that we
> >   do not support SME (this is part of TID1 traps)
> > 
> > - The "invariant" values that KVM presents to userspace originate from
> >   the boot CPU, not the CPU that resets the ID registers for a VM
> > 
> > - A VMM that wants to present big-little can do so on current KVM by
> >   affining vCPUs, but cannot with this series
> > 
> > All of this is to say, I think your series is going to collide with
> > the pre-existing pile of crap we have. I'm going to pick up these
> > changes and rework them so we can send a fix for #1 to stable trees and
> > (hopefully) avoid breaking the old "invariant" behavior.
> > 
> > I'll post what I have as soon as I test it, hopefully we can get this
> > shaped up for 6.15.
> 
> Sry, for the additional work I've caused. I gave what you have in next a
> spin and it looks good so far.
> Thank you very much!

Don't apologize -- it isn't your fault what we had already was a mess! :)

Thanks for kicking the tires.

Best,
Oliver