[GIT PULL] KVM/arm64 fixes for 6.18, take #1

[GIT PULL] KVM/arm64 fixes for 6.18, take #1

[Marc Zyngier]

Paolo,

As 6.18-rc1 is out, here's a collection of fixes that have accumulated
over the past 3 weeks, addressing a pretty wide ranging set of issues.
Nothing really jumps out, for once, and it's the usual mix of UAPI
tidy-up, architecture fixups, and other random cleanups. Maybe a few
more selftest updates than we usually do, but I'm sure this isn't
going to last!

I'm already looking at some more fixes, so will probably be back next
week with more presents...

You will notice that, just like I did with the main pull request, I'm
adding message-ids to the tag instead of putting them into the
individual patches. It looks rubbish, but I don't have a good
alternative, and I'm not prepared to remove provenance information
from the stuff I ferry upstream.

I'd welcome any guidance that would make things suck less for people
reporting bugs and backporting stuff, despite the "Link: is bad"
nonsense. Preferably something that we can adopt across architectures
supporting KVM.

In the meantime, please pull.

	M.

The following changes since commit 3a8660878839faadb4f1a6dd72c3179c1df56787:

  Linux 6.18-rc1 (2025-10-12 13:42:36 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-fixes-6.18-1

for you to fetch changes up to ca88ecdce5f51874a7c151809bd2c936ee0d3805:

  arm64: Revamp HCR_EL2.E2H RES1 detection (2025-10-14 08:18:40 +0100)

----------------------------------------------------------------
KVM/arm64 fixes for 6.18, take #1

Improvements and bug fixes:

- Fix the handling of ZCR_EL2 in NV VMs
  (20250926194108.84093-1-oliver.upton@linux.dev)

- Pick the correct translation regime when doing a PTW on
  the back of a SEA (20250926224246.731748-1-oliver.upton@linux.dev)

- Prevent userspace from injecting an event into a vcpu that isn't
  initialised yet (20250930085237.108326-1-oliver.upton@linux.dev)

- Move timer save/restore to the sysreg handling code, fixing EL2 timer
  access in the process (20250929160458.3351788-1-maz@kernel.org)

- Add FGT-based trapping of MDSCR_EL1 to reduce the overhead of debug
  (20250924235150.617451-1-oliver.upton@linux.dev)

- Fix trapping configuration when the host isn't GICv3
  (20251007160704.1673584-1-sascha.bischoff@arm.com)

- Improve the detection of HCR_EL2.E2H being RES1
  (20251009121239.29370-1-maz@kernel.org)

- Drop a spurious 'break' statement in the S1 PTW
  (20250930135621.162050-1-osama.abdelkader@gmail.com)

- Don't try to access SPE when owned by EL3
  (20251010174707.1684200-1-mukesh.ojha@oss.qualcomm.com)

Documentation updates:

- Document the failure modes of event injection
  (20250930233620.124607-1-oliver.upton@linux.dev)

- Document that a GICv3 guest can be created on a GICv5 host
  with FEAT_GCIE_LEGACY (20251007154848.1640444-1-sascha.bischoff@arm.com)

Selftest improvements:

- Add a sesttest for the effective value of HCR_EL2.AMO
  (20250926224454.734066-1-oliver.upton@linux.dev)

- Address build warning in the timer selftest when building
  with clang (20250926155838.2612205-1-seanjc@google.com)

- Teach irq_fd selftests about non-x86 architectures
  (20250930193301.119859-1-oliver.upton@linux.dev)

- Add missing sysregs to the set_id_regs selftest
  (20251012154352.61133-1-zenghui.yu@linux.dev)

- Fix vcpu allocation in the vgic_lpi_stress selftest
  (20251008154520.54801-1-zenghui.yu@linux.dev)

- Correctly enable interrupts in the vgic_lpi_stress selftest
  (20251007195254.260539-1-oliver.upton@linux.dev)

----------------------------------------------------------------
Marc Zyngier (15):
      KVM: arm64: nv: Don't advance PC when pending an SVE exception
      KVM: arm64: Hide CNTHV_*_EL2 from userspace for nVHE guests
      KVM: arm64: Introduce timer_context_to_vcpu() helper
      KVM: arm64: Replace timer context vcpu pointer with timer_id
      KVM: arm64: Make timer_set_offset() generally accessible
      KVM: arm64: Add timer UAPI workaround to sysreg infrastructure
      KVM: arm64: Move CNT*_CTL_EL0 userspace accessors to generic infrastructure
      KVM: arm64: Move CNT*_CVAL_EL0 userspace accessors to generic infrastructure
      KVM: arm64: Move CNT*CT_EL0 userspace accessors to generic infrastructure
      KVM: arm64: Fix WFxT handling of nested virt
      KVM: arm64: Kill leftovers of ad-hoc timer userspace access
      KVM: arm64: selftests: Make dependencies on VHE-specific registers explicit
      KVM: arm64: selftests: Add an E2H=0-specific configuration to get_reg_list
      KVM: arm64: selftests: Fix misleading comment about virtual timer encoding
      arm64: Revamp HCR_EL2.E2H RES1 detection

Mukesh Ojha (1):
      KVM: arm64: Guard PMSCR_EL1 initialization with SPE presence check

Oliver Upton (9):
      KVM: arm64: nv: Don't treat ZCR_EL2 as a 'mapped' register
      KVM: arm64: Use the in-context stage-1 in __kvm_find_s1_desc_level()
      KVM: arm64: selftests: Test effective value of HCR_EL2.AMO
      KVM: arm64: Prevent access to vCPU events before init
      KVM: arm64: Document vCPU event ioctls as requiring init'ed vCPU
      KVM: selftests: Fix irqfd_test for non-x86 architectures
      KVM: arm64: selftests: Actually enable IRQs in vgic_lpi_stress
      KVM: arm64: Compute per-vCPU FGTs at vcpu_load()
      KVM: arm64: nv: Use FGT write trap of MDSCR_EL1 when available

Osama Abdelkader (1):
      KVM: arm64: Remove unreachable break after return

Sascha Bischoff (2):
      KVM: arm64: gic-v3: Only set ICH_HCR traps for v2-on-v3 or v3 guests
      Documentation: KVM: Update GICv3 docs for GICv5 hosts

Sean Christopherson (1):
      KVM: arm64: selftests: Track width of timer counter as "int", not "uint64_t"

Zenghui Yu (2):
      KVM: arm64: selftests: Sync ID_AA64PFR1, MPIDR, CLIDR in guest
      KVM: arm64: selftests: Allocate vcpus with correct size

 Documentation/virt/kvm/api.rst                     |   5 +
 Documentation/virt/kvm/devices/arm-vgic-v3.rst     |   3 +-
 arch/arm64/include/asm/el2_setup.h                 |  38 +++++-
 arch/arm64/include/asm/kvm_host.h                  |  50 +++++++
 arch/arm64/kvm/arch_timer.c                        | 105 ++-------------
 arch/arm64/kvm/arm.c                               |   7 +
 arch/arm64/kvm/at.c                                |   7 +-
 arch/arm64/kvm/config.c                            |  90 +++++++++++++
 arch/arm64/kvm/debug.c                             |  15 ++-
 arch/arm64/kvm/guest.c                             |  70 ----------
 arch/arm64/kvm/handle_exit.c                       |   7 +-
 arch/arm64/kvm/hyp/include/hyp/switch.h            | 148 +++------------------
 arch/arm64/kvm/hyp/nvhe/pkvm.c                     |   1 +
 arch/arm64/kvm/nested.c                            |   9 +-
 arch/arm64/kvm/sys_regs.c                          | 131 ++++++++++++++----
 arch/arm64/kvm/sys_regs.h                          |   6 +
 arch/arm64/kvm/vgic/vgic-v3.c                      |   5 +-
 include/kvm/arm_arch_timer.h                       |  24 ++--
 .../selftests/kvm/arm64/arch_timer_edge_cases.c    |   2 +-
 .../testing/selftests/kvm/arm64/external_aborts.c  |  43 ++++++
 tools/testing/selftests/kvm/arm64/get-reg-list.c   |  99 +++++++++++++-
 tools/testing/selftests/kvm/arm64/set_id_regs.c    |   3 +
 .../testing/selftests/kvm/arm64/vgic_lpi_stress.c  |   3 +-
 .../selftests/kvm/include/arm64/processor.h        |  12 +-
 tools/testing/selftests/kvm/include/kvm_util.h     |   2 +
 tools/testing/selftests/kvm/irqfd_test.c           |  14 +-
 tools/testing/selftests/kvm/lib/arm64/processor.c  |   5 +
 tools/testing/selftests/kvm/lib/kvm_util.c         |   5 +
 tools/testing/selftests/kvm/lib/s390/processor.c   |   5 +
 tools/testing/selftests/kvm/lib/x86/processor.c    |   5 +
 30 files changed, 565 insertions(+), 354 deletions(-)

Re: [GIT PULL] KVM/arm64 fixes for 6.18, take #1

[Paolo Bonzini]

On 10/14/25 14:28, Marc Zyngier wrote:
> Paolo,
> 
> As 6.18-rc1 is out, here's a collection of fixes that have accumulated
> over the past 3 weeks, addressing a pretty wide ranging set of issues.
> Nothing really jumps out, for once, and it's the usual mix of UAPI
> tidy-up, architecture fixups, and other random cleanups. Maybe a few
> more selftest updates than we usually do, but I'm sure this isn't
> going to last!
> 
> I'm already looking at some more fixes, so will probably be back next
> week with more presents...
> 
> You will notice that, just like I did with the main pull request, I'm
> adding message-ids to the tag instead of putting them into the
> individual patches. It looks rubbish, but I don't have a good
> alternative, and I'm not prepared to remove provenance information
> from the stuff I ferry upstream.
> 
> I'd welcome any guidance that would make things suck less for people
> reporting bugs and backporting stuff, despite the "Link: is bad"
> nonsense. Preferably something that we can adopt across architectures
> supporting KVM.
Because you're already unusually meticulous in tracking tags, I'm going 
to say whatever floats your boat.  If you want to add it to each patch, 
I'm certainly not going to be the one to complain, and/or to make your 
life harder, because of something like "Link".

Personally I think that there's a different between adding something 
mindlessly as a cargo cult, and adding it *unconditionally*.  Link is 
the latter, it's unconditional because it may be needed *later*.  In 
some cases it may not be strictly necessary (for example the tip bot 
used it to send replies, and that is served by notes just fine), but 
overall I don't get the hate either.

In fact, I'm very adamant about *needing* Link trailers for each patch 
in the RISC-V pull requests, which are the ones I look at most closely 
since the code is still in relative infancy.

Pulled, by the way. :)

Paolo

Re: [GIT PULL] KVM/arm64 fixes for 6.18, take #1

[Sean Christopherson]

On Wed, Oct 15, 2025, Paolo Bonzini wrote:
> On 10/14/25 14:28, Marc Zyngier wrote:
> > You will notice that, just like I did with the main pull request, I'm
> > adding message-ids to the tag instead of putting them into the
> > individual patches. It looks rubbish, but I don't have a good
> > alternative, and I'm not prepared to remove provenance information
> > from the stuff I ferry upstream.
> > 
> > I'd welcome any guidance that would make things suck less for people
> > reporting bugs and backporting stuff, despite the "Link: is bad"
> > nonsense. Preferably something that we can adopt across architectures
> > supporting KVM.
> Because you're already unusually meticulous in tracking tags, I'm going to
> say whatever floats your boat.  If you want to add it to each patch, I'm
> certainly not going to be the one to complain, and/or to make your life
> harder, because of something like "Link".
> 
> Personally I think that there's a different between adding something
> mindlessly as a cargo cult, and adding it *unconditionally*.  Link is the
> latter, it's unconditional because it may be needed *later*.  In some cases
> it may not be strictly necessary (for example the tip bot used it to send
> replies, and that is served by notes just fine), but overall I don't get the
> hate either.
> 
> In fact, I'm very adamant about *needing* Link trailers for each patch in
> the RISC-V pull requests, which are the ones I look at most closely since
> the code is still in relative infancy.

FWIW, adding Link to every commit is a hill I'll die on (and Paolo has confirmed
that he doesn't object), it's simply far too valuable.  And as Paolo has mentioned
off-list, I don't think Linus will ever notice, so long as we don't send him
garbage and thus give him cause to see what lies behind the Link.