From: Oliver Upton <oliver.upton@linux.dev>
To: Will Deacon <will@kernel.org>
Cc: Fuad Tabba <tabba@google.com>,
kvmarm@lists.linux.dev, maz@kernel.org, qperret@google.com,
seanjc@google.com, alexandru.elisei@arm.com,
catalin.marinas@arm.com, philmd@linaro.org, james.morse@arm.com,
suzuki.poulose@arm.com, mark.rutland@arm.com, broonie@kernel.org,
joey.gouly@arm.com, rananta@google.com, smostafa@google.com
Subject: Re: [PATCH v3 27/31] KVM: arm64: Use atomic refcount helpers for 'struct hyp_page::refcount'
Date: Mon, 22 Apr 2024 18:15:01 -0700 [thread overview]
Message-ID: <ZicLldy92RDCa4BX@linux.dev> (raw)
In-Reply-To: <20240422234432.GA6818@willie-the-truck>
On Tue, Apr 23, 2024 at 12:44:32AM +0100, Will Deacon wrote:
> Hi Oliver,
>
> On Mon, Apr 22, 2024 at 01:46:14PM -0700, Oliver Upton wrote:
> > On Mon, Apr 22, 2024 at 02:08:17PM +0100, Fuad Tabba wrote:
> >
> > [...]
> >
> > > > > Adding a BUG_ON() for taking a reference on a non-refcounted page (i.e.
> > > > > p->refcount was 0) would be nice, especially since we're past the point of
> > > > > serializing everything and you can theoretically have a zero count page
> > > > > outside of the free list.
> > > > >
> > > > > Seems like otherwise we'd get actually hit the BUG_ON() in an unrelated
> > > > > allocation path.
> > >
> > > Actually, the refcount can be 0 without it being an error. For
> > > example, when hyp pins memory shared with it by the host
> > > (mem_protect.c:hyp_pin_shared_mem()).
> >
> > Are those not by their very definition non-refcounted pages?
>
> Right, we're using the refcount for two things here: (1) so that the
> allocator knows when to return the page to the pool and (2) so that the
> hypervisor can transiently prevent a page which has been shared by the
> host from being unshared. That second part is needed to e.g. prevent a
> page holding a host vCPU structure being donated to a guest as normal
> memory and then having the hypervisor write to it as a result of a host
> hypercall. We use the refcount for this because the same page can be
> shared with the hypervisor multiple times and we need to know when the
> last host sharer has dropped its pin.
Ah, right. I don't have the muscle memory for the pKVM bits upstream
(even though I should), I missed the very obvious refcount test in
hyp_ack_unshare().
So it is a refcount on the page state, be it allocated or shared. And
the 0 -> 1 transition on a shared page happens through an increment
rather than an initializer like pages from the hyp pool.
> > I can't imagine we'd want pages in a shared state with the host to ever
> > get returned to the hyp allocator. Seems an erroneous hyp_put_page() would
> > get you there, though.
>
> Given the dual-use above, I don't think a BUG_ON() on the refcount is
> the right fix. Instead, we'd probably want a (cheap) mechanism to
> differentiate pages in states (1) and (2). This could be a new flag in
> 'struct hyp_page' or perhaps we could be creative and set the 'order' to
> HYP_NO_ORDER for pinned pages and then have a BUG() to check 'p->order'
> against 'pool->max_order' in hyp_put_page().
>
> What do you think?
Excellent idea. Having a way to disambiguate page states would be great,
all the better if it can (ab)use an existing field.
--
Thanks,
Oliver
next prev parent reply other threads:[~2024-04-23 1:15 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-19 7:59 [PATCH v3 00/31] KVM: arm64: Preamble for pKVM Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 01/31] KVM: arm64: Initialize the kvm host data's fpsimd_state pointer in pKVM Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 02/31] KVM: arm64: Move guest_owns_fp_regs() to increase its scope Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 03/31] KVM: arm64: Refactor checks for FP state ownership Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 04/31] KVM: arm64: Do not re-initialize the KVM lock Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 05/31] KVM: arm64: Issue CMOs when tearing down guest s2 pages Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 06/31] KVM: arm64: Avoid BUG-ing from the host abort path Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 07/31] KVM: arm64: Check for PTE validity when checking for executable/cacheable Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 08/31] KVM: arm64: Avoid BBM when changing only s/w bits in Stage-2 PTE Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 09/31] KVM: arm64: Support TLB invalidation in guest context Fuad Tabba
2024-04-19 20:54 ` Oliver Upton
2024-04-22 8:11 ` Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 10/31] KVM: arm64: Do not map the host fpsimd state to hyp in pKVM Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 11/31] KVM: arm64: Remove locking from EL2 allocation fast-paths Fuad Tabba
2024-04-19 20:42 ` Oliver Upton
2024-04-22 8:09 ` Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 12/31] KVM: arm64: Prevent kmemleak from accessing .hyp.data Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 13/31] KVM: arm64: Fix comment for __pkvm_vcpu_init_traps() Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 14/31] KVM: arm64: Change kvm_handle_mmio_return() return polarity Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 15/31] KVM: arm64: Move setting the page as dirty out of the critical section Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 16/31] KVM: arm64: Simplify vgic-v3 hypercalls Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 17/31] KVM: arm64: Add is_pkvm_initialized() helper Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 18/31] KVM: arm64: Introduce and use predicates that check for protected VMs Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 19/31] KVM: arm64: Move pstate reset value definitions to kvm_arm.h Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 20/31] KVM: arm64: Clarify rationale for ZCR_EL1 value restored on guest exit Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 21/31] KVM: arm64: Refactor calculating SVE state size to use helpers Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 22/31] KVM: arm64: Move some kvm_psci functions to a shared header Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 23/31] KVM: arm64: Refactor reset_mpidr() to extract its computation Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 24/31] KVM: arm64: Refactor kvm_vcpu_enable_ptrauth() for hyp use Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 25/31] KVM: arm64: Introduce hyp_rwlock_t Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 26/31] KVM: arm64: Add atomics-based checking refcount implementation at EL2 Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 27/31] KVM: arm64: Use atomic refcount helpers for 'struct hyp_page::refcount' Fuad Tabba
2024-04-19 20:52 ` Oliver Upton
2024-04-22 8:10 ` Fuad Tabba
2024-04-22 13:08 ` Fuad Tabba
2024-04-22 20:46 ` Oliver Upton
2024-04-22 23:44 ` Will Deacon
2024-04-23 1:15 ` Oliver Upton [this message]
2024-04-19 7:59 ` [PATCH v3 28/31] KVM: arm64: Reformat/beautify PTP hypercall documentation Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 29/31] KVM: arm64: Rename firmware pseudo-register documentation file Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 30/31] KVM: arm64: Document the KVM/arm64-specific calls in hypercalls.rst Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 31/31] KVM: arm64: Force injection of a data abort on NISV MMIO exit Fuad Tabba
2024-04-19 20:28 ` Oliver Upton
2024-04-22 8:07 ` 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=ZicLldy92RDCa4BX@linux.dev \
--to=oliver.upton@linux.dev \
--cc=alexandru.elisei@arm.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=philmd@linaro.org \
--cc=qperret@google.com \
--cc=rananta@google.com \
--cc=seanjc@google.com \
--cc=smostafa@google.com \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=will@kernel.org \
/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.