The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Quentin Perret <qperret@google.com>
To: Marc Zyngier <maz@kernel.org>,
	Oliver Upton <oliver.upton@linux.dev>,
	 Joey Gouly <joey.gouly@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	 Zenghui Yu <yuzenghui@huawei.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	 Will Deacon <will@kernel.org>
Cc: Fuad Tabba <tabba@google.com>,
	Vincent Donnefort <vdonnefort@google.com>,
	 linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	 linux-kernel@vger.kernel.org
Subject: [PATCH 0/3] KVM: arm64: Simplify pKVM memory transitions
Date: Fri, 10 Jan 2025 12:19:33 +0000	[thread overview]
Message-ID: <20250110121936.1559655-1-qperret@google.com> (raw)

Since its early days, pKVM has formalized memory 'transitions' (shares
and donations) using 'struct pkvm_mem_transition' and bunch of helpers
to manipulate it. The intention was for all transitions to use this
machinery to ensure we're checking things consistently. However, as
development progressed, it became clear that the rigidity of this model
made it really difficult to use in some use-cases which ended-up
side-stepping it entirely. That is the case for the
hyp_{un}pin_shared_mem() and host_{un}share_guest() paths upstream which
use lower level helpers directly, as well as for several other pKVM
features that should land upstream in the future (ex: when a guest
relinquishes a page during ballooning, when annotating a page that is
being DMA'd to, ...). On top of this, the pkvm_mem_transition machinery
requires a lot of boilerplate which makes the code hard to read, but
also adds layers of indirection that no compilers seems to see through,
hence leading to suboptimal generated code.

Given all the above, this series removes the pkvm_mem_transition
machinery from mem_protect.c, and converts all its users to use
__*_{check,set}_page_state_range() low-level helpers directly.

A few things to note:

 - the existing helpers to request, ack, initiate and complete
   transitions were mostly wrappers around
   __*_{check,set}_page_state_range() anyways, so we're not losing that
   much in terms of consistency

 - the pkvm_mem_transition machinery did not suffice to avoid bugs such
   as [1]. The pkvm selftest [2] should do a much better job at that

 - see diffstat ;-)

This series depends on support for NP guest stage-2 for pKVM [3] as well
as the fix in [1]. I've pushed a branch with all the goodies applied [4]
if that can be useful.

Thanks,
Quentin

[1] https://lore.kernel.org/kvmarm/20241128154406.602875-1-qperret@google.com/
[2] https://lore.kernel.org/kvmarm/20241129125800.992468-1-qperret@google.com/
[3] https://lore.kernel.org/kvmarm/20241218194059.3670226-1-qperret@google.com/
[4] https://android-kvm.googlesource.com/linux/+/refs/heads/qperret/no-mem-tx

Quentin Perret (3):
  KVM: arm64: Drop pkvm_mem_transition for FF-A
  KVM: arm64: Drop pkvm_mem_transition for host/hyp sharing
  KVM: arm64: Drop pkvm_mem_transition for host/hyp donations

 arch/arm64/kvm/hyp/nvhe/mem_protect.c | 640 +++-----------------------
 1 file changed, 76 insertions(+), 564 deletions(-)

-- 
2.47.1.688.g23fc6f90ad-goog


             reply	other threads:[~2025-01-10 12:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-10 12:19 Quentin Perret [this message]
2025-01-10 12:19 ` [PATCH 1/3] KVM: arm64: Drop pkvm_mem_transition for FF-A Quentin Perret
2025-01-10 12:19 ` [PATCH 2/3] KVM: arm64: Drop pkvm_mem_transition for host/hyp sharing Quentin Perret
2025-01-10 12:19 ` [PATCH 3/3] KVM: arm64: Drop pkvm_mem_transition for host/hyp donations Quentin Perret
2025-01-12 10:42 ` [PATCH 0/3] KVM: arm64: Simplify pKVM memory transitions Marc Zyngier

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=20250110121936.1559655-1-qperret@google.com \
    --to=qperret@google.com \
    --cc=catalin.marinas@arm.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=oliver.upton@linux.dev \
    --cc=suzuki.poulose@arm.com \
    --cc=tabba@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox