From: Kalesh Singh <kaleshsingh@google.com>
To: Fuad Tabba <tabba@google.com>
Cc: Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
Quentin Perret <qperret@google.com>,
Suren Baghdasaryan <surenb@google.com>,
"Cc: Android Kernel" <kernel-team@android.com>,
James Morse <james.morse@arm.com>,
Alexandru Elisei <alexandru.elisei@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Mark Brown <broonie@kernel.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Peter Collingbourne <pcc@google.com>,
"Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>,
Andrew Walbran <qwandor@google.com>,
Andrew Scull <ascull@google.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Ard Biesheuvel <ardb@kernel.org>,
"moderated list:ARM64 PORT (AARCH64 ARCHITECTURE)"
<linux-arm-kernel@lists.infradead.org>,
kvmarm@lists.cs.columbia.edu, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 2/8] KVM: arm64: Introduce pkvm_alloc_private_va_range()
Date: Thu, 24 Feb 2022 09:28:24 -0800 [thread overview]
Message-ID: <CAC_TJvcCcv0ENHfpMHBzNMJVtBpjAKqJ_aO_HtKk2uBw+O9Y9A@mail.gmail.com> (raw)
In-Reply-To: <CA+EHjTw=6AUCWtpNFBtw+AxRskF3cg6284rGdes9W9S8Be_xww@mail.gmail.com>
On Thu, Feb 24, 2022 at 4:26 AM Fuad Tabba <tabba@google.com> wrote:
>
> Hi Kalesh,
>
> I really like how this makes the code cleaner in general. A couple of
> small nits below.
>
> On Thu, Feb 24, 2022 at 5:17 AM 'Kalesh Singh' via kernel-team
> <kernel-team@android.com> wrote:
> >
> > pkvm_hyp_alloc_private_va_range() can be used to reserve private VA ranges
> > in the pKVM nVHE hypervisor (). Also update __pkvm_create_private_mapping()
> > to allow specifying an alignment for the private VA mapping.
> >
> > These will be used to implement stack guard pages for pKVM nVHE hypervisor
> > (in a subsequent patch in the series).
> >
> > Credits to Quentin Perret <qperret@google.com> for the idea of moving
> > private VA allocation out of __pkvm_create_private_mapping()
> >
> > Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
> > ---
> >
> > Changes in v3:
> > - Handle null ptr in IS_ERR_OR_NULL checks, per Mark
> >
> > Changes in v2:
> > - Allow specifying an alignment for the private VA allocations, per Marc
> >
> > arch/arm64/kvm/hyp/include/nvhe/mm.h | 3 +-
> > arch/arm64/kvm/hyp/nvhe/hyp-main.c | 5 +--
> > arch/arm64/kvm/hyp/nvhe/mm.c | 51 ++++++++++++++++++----------
> > arch/arm64/kvm/mmu.c | 2 +-
> > 4 files changed, 40 insertions(+), 21 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/hyp/include/nvhe/mm.h b/arch/arm64/kvm/hyp/include/nvhe/mm.h
> > index 2d08510c6cc1..05d06ad00347 100644
> > --- a/arch/arm64/kvm/hyp/include/nvhe/mm.h
> > +++ b/arch/arm64/kvm/hyp/include/nvhe/mm.h
> > @@ -20,7 +20,8 @@ int pkvm_cpu_set_vector(enum arm64_hyp_spectre_vector slot);
> > int pkvm_create_mappings(void *from, void *to, enum kvm_pgtable_prot prot);
> > int pkvm_create_mappings_locked(void *from, void *to, enum kvm_pgtable_prot prot);
> > unsigned long __pkvm_create_private_mapping(phys_addr_t phys, size_t size,
> > - enum kvm_pgtable_prot prot);
> > + size_t align, enum kvm_pgtable_prot prot);
>
> Minor nit: the alignment of this does not match how it was before,
> i.e., it's not in line with the other function parameters. Yet it
> still goes over 80 characters.
Ack
>
> > +unsigned long pkvm_alloc_private_va_range(size_t size, size_t align);
> >
> > static inline void hyp_vmemmap_range(phys_addr_t phys, unsigned long size,
> > unsigned long *start, unsigned long *end)
> > diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > index 5e2197db0d32..96b2312a0f1d 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > @@ -158,9 +158,10 @@ static void handle___pkvm_create_private_mapping(struct kvm_cpu_context *host_ct
> > {
> > DECLARE_REG(phys_addr_t, phys, host_ctxt, 1);
> > DECLARE_REG(size_t, size, host_ctxt, 2);
> > - DECLARE_REG(enum kvm_pgtable_prot, prot, host_ctxt, 3);
> > + DECLARE_REG(size_t, align, host_ctxt, 3);
> > + DECLARE_REG(enum kvm_pgtable_prot, prot, host_ctxt, 4);
> >
> > - cpu_reg(host_ctxt, 1) = __pkvm_create_private_mapping(phys, size, prot);
> > + cpu_reg(host_ctxt, 1) = __pkvm_create_private_mapping(phys, size, align, prot);
> > }
> >
> > static void handle___pkvm_prot_finalize(struct kvm_cpu_context *host_ctxt)
> > diff --git a/arch/arm64/kvm/hyp/nvhe/mm.c b/arch/arm64/kvm/hyp/nvhe/mm.c
> > index 526a7d6fa86f..f35468ec639d 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/mm.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/mm.c
> > @@ -37,26 +37,46 @@ static int __pkvm_create_mappings(unsigned long start, unsigned long size,
> > return err;
> > }
> >
> > -unsigned long __pkvm_create_private_mapping(phys_addr_t phys, size_t size,
> > - enum kvm_pgtable_prot prot)
> > +/*
> > + * Allocates a private VA range above __io_map_base.
> > + *
> > + * @size: The size of the VA range to reserve.
> > + * @align: The required alignment for the allocation.
> > + */
> > +unsigned long pkvm_alloc_private_va_range(size_t size, size_t align)
> > {
> > - unsigned long addr;
> > - int err;
> > + unsigned long base, addr;
> >
> > hyp_spin_lock(&pkvm_pgd_lock);
> >
> > - size = PAGE_ALIGN(size + offset_in_page(phys));
> > - addr = __io_map_base;
> > - __io_map_base += size;
> > + addr = ALIGN(__io_map_base, align);
> > +
> > + /* The allocated size is always a multiple of PAGE_SIZE */
> > + base = addr + PAGE_ALIGN(size);
> >
> > /* Are we overflowing on the vmemmap ? */
> > - if (__io_map_base > __hyp_vmemmap) {
> > - __io_map_base -= size;
> > + if (base > __hyp_vmemmap)
> > addr = (unsigned long)ERR_PTR(-ENOMEM);
> > + else
> > + __io_map_base = base;
> > +
> > + hyp_spin_unlock(&pkvm_pgd_lock);
> > +
> > + return addr;
> > +}
> > +
> > +unsigned long __pkvm_create_private_mapping(phys_addr_t phys, size_t size,
> > + size_t align, enum kvm_pgtable_prot prot)
> > +{
> > + unsigned long addr;
> > + int err;
> > +
> > + size += offset_in_page(phys);
>
> Same as in the patch before, the previous code would align the size
> but not this change. However, looking at the callers and callees this
> seems to be fine, since it's aligned when needed.
This is now handled by pkvm_alloc_private_va_range(), so caller doesn't need to:
...
/* The allocated size is always a multiple of PAGE_SIZE */
base = addr + PAGE_ALIGN(size);
...
Thanks,
Kalesh
>
> Thanks,
> /fuad
>
> > + addr = pkvm_alloc_private_va_range(size, align);
> > + if (IS_ERR((void *)addr))
> > goto out;
> > - }
> >
> > - err = kvm_pgtable_hyp_map(&pkvm_pgtable, addr, size, phys, prot);
> > + err = __pkvm_create_mappings(addr, size, phys, prot);
> > if (err) {
> > addr = (unsigned long)ERR_PTR(err);
> > goto out;
> > @@ -64,8 +84,6 @@ unsigned long __pkvm_create_private_mapping(phys_addr_t phys, size_t size,
> >
> > addr = addr + offset_in_page(phys);
> > out:
> > - hyp_spin_unlock(&pkvm_pgd_lock);
> > -
> > return addr;
> > }
> >
> > @@ -152,11 +170,10 @@ int hyp_map_vectors(void)
> > return 0;
> >
> > phys = __hyp_pa(__bp_harden_hyp_vecs);
> > - bp_base = (void *)__pkvm_create_private_mapping(phys,
> > - __BP_HARDEN_HYP_VECS_SZ,
> > - PAGE_HYP_EXEC);
> > + bp_base = (void *)__pkvm_create_private_mapping(phys, __BP_HARDEN_HYP_VECS_SZ,
> > + PAGE_SIZE, PAGE_HYP_EXEC);
> > if (IS_ERR_OR_NULL(bp_base))
> > - return PTR_ERR(bp_base);
> > + return bp_base ? PTR_ERR(bp_base) : -ENOMEM;
> >
> > __hyp_bp_vect_base = bp_base;
> >
> > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > index fc09536c8197..298e6d8439ef 100644
> > --- a/arch/arm64/kvm/mmu.c
> > +++ b/arch/arm64/kvm/mmu.c
> > @@ -505,7 +505,7 @@ int __create_hyp_private_mapping(phys_addr_t phys_addr, size_t size,
> >
> > if (!kvm_host_owns_hyp_mappings()) {
> > addr = kvm_call_hyp_nvhe(__pkvm_create_private_mapping,
> > - phys_addr, size, prot);
> > + phys_addr, size, align, prot);
> > if (IS_ERR_OR_NULL((void *)addr))
> > return addr ? PTR_ERR((void *)addr) : -ENOMEM;
> > *haddr = addr;
> > --
> > 2.35.1.473.g83b2b277ed-goog
> >
> > --
> > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com.
> >
next prev parent reply other threads:[~2022-02-24 17:29 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-24 5:13 [PATCH v3 0/8] KVM: arm64: Hypervisor stack enhancements Kalesh Singh
2022-02-24 5:13 ` [PATCH v3 1/8] KVM: arm64: Introduce hyp_alloc_private_va_range() Kalesh Singh
2022-02-24 12:24 ` Fuad Tabba
2022-02-24 17:20 ` Kalesh Singh
2022-02-24 5:13 ` [PATCH v3 2/8] KVM: arm64: Introduce pkvm_alloc_private_va_range() Kalesh Singh
2022-02-24 12:25 ` Fuad Tabba
2022-02-24 17:28 ` Kalesh Singh [this message]
2022-02-24 5:13 ` [PATCH v3 3/8] KVM: arm64: Add guard pages for KVM nVHE hypervisor stack Kalesh Singh
2022-02-24 12:26 ` Fuad Tabba
2022-02-24 17:54 ` Kalesh Singh
2022-02-24 5:13 ` [PATCH v3 4/8] KVM: arm64: Add guard pages for pKVM (protected nVHE) " Kalesh Singh
2022-02-24 5:13 ` [PATCH v3 5/8] KVM: arm64: Detect and handle hypervisor stack overflows Kalesh Singh
2022-02-24 5:13 ` [PATCH v3 6/8] KVM: arm64: Add hypervisor overflow stack Kalesh Singh
2022-02-24 12:26 ` Fuad Tabba
2022-02-24 17:56 ` Kalesh Singh
2022-02-24 5:13 ` [PATCH v3 7/8] KVM: arm64: Unwind and dump nVHE HYP stacktrace Kalesh Singh
2022-02-24 12:28 ` Fuad Tabba
2022-02-24 18:08 ` Kalesh Singh
2022-02-24 5:13 ` [PATCH v3 8/8] KVM: arm64: Symbolize the nVHE HYP backtrace Kalesh Singh
2022-02-25 3:59 ` [PATCH v3 0/8] KVM: arm64: Hypervisor stack enhancements Kalesh Singh
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=CAC_TJvcCcv0ENHfpMHBzNMJVtBpjAKqJ_aO_HtKk2uBw+O9Y9A@mail.gmail.com \
--to=kaleshsingh@google.com \
--cc=alexandru.elisei@arm.com \
--cc=ardb@kernel.org \
--cc=ascull@google.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=kernel-team@android.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=madvenka@linux.microsoft.com \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=mhiramat@kernel.org \
--cc=pbonzini@redhat.com \
--cc=pcc@google.com \
--cc=qperret@google.com \
--cc=qwandor@google.com \
--cc=surenb@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).