From: Fuad Tabba <tabba@google.com>
To: Marc Zyngier <maz@kernel.org>, Oliver Upton <oupton@kernel.org>,
kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Joey Gouly <joey.gouly@arm.com>,
Steffen Eiden <seiden@linux.ibm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Vincent Donnefort <vdonnefort@google.com>,
Quentin Perret <qperret@google.com>,
Sebastian Ene <sebastianene@google.com>,
Hyunwoo Kim <imv4bel@gmail.com>, Fuad Tabba <tabba@google.com>
Subject: [PATCH 0/8] KVM: arm64: Rework pKVM vCPU state synchronisation
Date: Fri, 19 Jun 2026 08:05:00 +0100 [thread overview]
Message-ID: <20260619070508.802802-1-tabba@google.com> (raw)
Hi folks,
Changes since v1 [2]:
- Dropped the guard()/scoped_guard() conversion patches: standalone churn
on code this series does not otherwise rework. (Marc)
- Rebased onto kvmarm/next. The VGIC flush primitive now bounds used_lrs
using the cached hyp_gicv3_nr_lr instead of reading ICH_VTR_EL2 on every
entry. (Marc)
- Grouped the PKVM_HOST_STATE_DIRTY flag with the other iflags and
clarified its comment. (Marc)
- Sync PSTATE alongside PC on every non-protected exit, and sync+dirty
before host-side SError injection so the syndrome is not dropped. (sashiko)
- Various cleanups and tidying up. (Vincent)
Building on Will's pKVM infrastructure series [1], this series reworks
how pKVM moves vCPU state between the host and EL2, and stops copying a
non-protected guest's state on every world switch.
EL2 gains proper primitives for the state it transfers: vCPU lookup
helpers, and VGIC flush/sync that reduces how much host state EL2
dereferences. The series also moves some preparatory code (such as sys
reg access and PSCI helpers) to shared headers and HYP, and implements
lazy copying of a non-protected guest's register state back to the host
until the host actually needs it, instead of on every exit.
This is the first of two series moving pKVM vCPU state management to
EL2. The follow-up completes the job for protected VMs: state
isolation, PSCI handling at EL2, and the resulting API behaviour.
The series is structured as follows:
01-04: Preparatory refactoring (MPIDR, sys reg access, vCPU reset, PSCI
helpers) to shared headers and HYP.
05: Host and hypervisor vCPU lookup primitives.
06-07: VGIC: reduce EL2's exposure to host state, add flush/sync primitives.
08: Lazy state sync for non-protected guests.
Based on kvmarm/next.
[1] https://lore.kernel.org/all/20260105154939.11041-1-will@kernel.org/
[2] https://lore.kernel.org/all/20260612065925.755562-1-tabba@google.com/
Cheers,
/fuad
Fuad Tabba (5):
KVM: arm64: Extract MPIDR computation into a shared header
KVM: arm64: Make vcpu_{read,write}_sys_reg available to HYP code
KVM: arm64: Factor out reusable vCPU reset helpers
KVM: arm64: Move PSCI helper functions to a shared header
KVM: arm64: Implement lazy vCPU state sync for non-protected guests
Marc Zyngier (3):
KVM: arm64: Add host and hypervisor vCPU lookup primitives
KVM: arm64: Minimise EL2's exposure of host VGIC state during world
switch
KVM: arm64: Add primitives to flush/sync the VGIC state at EL2
arch/arm64/include/asm/kvm_arm.h | 12 ++
arch/arm64/include/asm/kvm_asm.h | 1 +
arch/arm64/include/asm/kvm_emulate.h | 79 +++++++-
arch/arm64/include/asm/kvm_host.h | 2 +
arch/arm64/kvm/arm.c | 7 +
arch/arm64/kvm/handle_exit.c | 30 ++++
arch/arm64/kvm/hyp/exception.c | 34 +---
arch/arm64/kvm/hyp/nvhe/hyp-main.c | 258 +++++++++++++++++++++++----
arch/arm64/kvm/psci.c | 30 +---
arch/arm64/kvm/reset.c | 60 +------
arch/arm64/kvm/sys_regs.c | 14 +-
arch/arm64/kvm/sys_regs.h | 19 ++
include/kvm/arm_psci.h | 27 +++
13 files changed, 410 insertions(+), 163 deletions(-)
--
2.55.0.rc0.738.g0c8ab3ebcc-goog
next reply other threads:[~2026-06-19 7:05 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-19 7:05 Fuad Tabba [this message]
2026-06-19 7:05 ` [PATCH 1/8] KVM: arm64: Extract MPIDR computation into a shared header Fuad Tabba
2026-06-19 7:05 ` [PATCH 2/8] KVM: arm64: Make vcpu_{read,write}_sys_reg available to HYP code Fuad Tabba
2026-06-19 7:05 ` [PATCH 3/8] KVM: arm64: Factor out reusable vCPU reset helpers Fuad Tabba
2026-06-19 7:05 ` [PATCH 4/8] KVM: arm64: Move PSCI helper functions to a shared header Fuad Tabba
2026-06-19 7:16 ` sashiko-bot
2026-06-19 7:24 ` Fuad Tabba
2026-06-19 7:05 ` [PATCH 5/8] KVM: arm64: Add host and hypervisor vCPU lookup primitives Fuad Tabba
2026-06-19 7:05 ` [PATCH 6/8] KVM: arm64: Minimise EL2's exposure of host VGIC state during world switch Fuad Tabba
2026-06-19 7:22 ` sashiko-bot
2026-06-19 7:29 ` Fuad Tabba
2026-06-19 7:05 ` [PATCH 7/8] KVM: arm64: Add primitives to flush/sync the VGIC state at EL2 Fuad Tabba
2026-06-19 7:05 ` [PATCH 8/8] KVM: arm64: Implement lazy vCPU state sync for non-protected guests Fuad Tabba
2026-06-19 7:24 ` sashiko-bot
2026-06-19 7:55 ` Fuad Tabba
2026-06-19 7:06 ` [PATCH 0/8] KVM: arm64: Rework pKVM vCPU state synchronisation Fuad Tabba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260619070508.802802-1-tabba@google.com \
--to=tabba@google.com \
--cc=catalin.marinas@arm.com \
--cc=imv4bel@gmail.com \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=qperret@google.com \
--cc=sebastianene@google.com \
--cc=seiden@linux.ibm.com \
--cc=suzuki.poulose@arm.com \
--cc=vdonnefort@google.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.