[GIT PULL] KVM/arm64 fixes for 7.0, take #4

[GIT PULL] KVM/arm64 fixes for 7.0, take #4

[Marc Zyngier]

Paolo,

Another week, another set of fixes. This time, another two fixes,
mostly observable with nested virt. The first one results in a vcpu
coming out of reset potentially skipping the first instruction at its
initial PC. The second one is a classic example of pointer arithmetic
going wrong in our address translation emulation, setting the access
bit in semi-random places. Both are stable candidates.

Please pull,

	M.

The following changes since commit a79f7b4aeb8e7562cd6dbf9c223e2c2a04b1a85f:

  KVM: arm64: pkvm: Don't reprobe for ICH_VTR_EL2.TDS on CPU hotplug (2026-03-10 09:48:45 +0000)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-fixes-7.0-4

for you to fetch changes up to 0496acc42fb51eee040b5170cec05cec41385540:

  KVM: arm64: Fix the descriptor address in __kvm_at_swap_desc() (2026-03-17 13:40:00 +0000)

----------------------------------------------------------------
KVM/arm64 fixes for 7.0, take #4

- Clear the pending exception state from a vcpu coming out of
  reset, as it could otherwise affect the first instruction
  executed in the guest.

- Fix the address translation emulation icode to set the Hardware
  Access bit on the correct PTE instead of some other location.

----------------------------------------------------------------
Marc Zyngier (1):
      KVM: arm64: Discard PC update state on vcpu reset

Zenghui Yu (Huawei) (1):
      KVM: arm64: Fix the descriptor address in __kvm_at_swap_desc()

 arch/arm64/kvm/at.c    |  2 +-
 arch/arm64/kvm/reset.c | 14 ++++++++++++++
 2 files changed, 15 insertions(+), 1 deletion(-)

Re: [GIT PULL] KVM/arm64 fixes for 7.0, take #4

[Paolo Bonzini]

On Fri, Mar 20, 2026 at 10:42 AM Marc Zyngier <maz@kernel.org> wrote:
>
> Paolo,
>
> Another week, another set of fixes. This time, another two fixes,
> mostly observable with nested virt. The first one results in a vcpu
> coming out of reset potentially skipping the first instruction at its
> initial PC. The second one is a classic example of pointer arithmetic
> going wrong in our address translation emulation, setting the access
> bit in semi-random places. Both are stable candidates.

Pulled, thanks.

Paolo