From: Marc Zyngier <maz@kernel.org>
To: Kalesh Singh <kaleshsingh@google.com>
Cc: "moderated list:ARM64 PORT \(AARCH64 ARCHITECTURE\)"
<linux-arm-kernel@lists.infradead.org>,
Will Deacon <will@kernel.org>,
Peter Collingbourne <pcc@google.com>,
"Cc: Android Kernel" <kernel-team@android.com>,
LKML <linux-kernel@vger.kernel.org>,
kvmarm <kvmarm@lists.cs.columbia.edu>,
"Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>,
Mark Brown <broonie@kernel.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Suren Baghdasaryan <surenb@google.com>
Subject: Re: [PATCH v4 2/8] KVM: arm64: Introduce pkvm_alloc_private_va_range()
Date: Thu, 03 Mar 2022 17:29:33 +0000 [thread overview]
Message-ID: <87r17j0wsi.wl-maz@kernel.org> (raw)
In-Reply-To: <CAC_TJvfTZP9+EKFFXQUeGOWJb=WK2Wkd53bPOX2gaz0Gh5o8OA@mail.gmail.com>
Hi Kalesh,
On Wed, 02 Mar 2022 17:24:53 +0000,
Kalesh Singh <kaleshsingh@google.com> wrote:
>
> On Tue, Mar 1, 2022 at 11:46 PM Marc Zyngier <maz@kernel.org> wrote:
> >
> > On Fri, 25 Feb 2022 03:34:47 +0000,
> > Kalesh Singh <kaleshsingh@google.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 v4:
> > > - Handle null ptr in pkvm_alloc_private_va_range() and replace
> > > IS_ERR_OR_NULL checks in callers with IS_ERR checks, per Fuad
> > > - Fix kernel-doc comments format, per Fuad
> > > - Format __pkvm_create_private_mapping() prototype args (< 80 col), per Fuad
> > >
> > > 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
> >
> > I probably badly expressed my earlier concern.
> >
> > Yes, an alignment is necessary. But how often do we want an alignment
> > that isn't naturally aligned to the size of the allocation (i.e. the
> > power of 2 >= the size of the allocation)? This is what the rest of
> > the kernel does (get_order() and co), and I thing we should follow
> > this.
>
> Hi Marc,
>
> Thanks for clarifying. I think making the alignment implicitly based
> on the size here will create unnecessary holes where PAGE_SIZE
> alignment would be ok and potentially overflow the private VA space
> earlier. Is it not a concern?
I don't think we should worry too much about this. Even when building
the kernel with a very small VA space (commonly 39 bits), we still
have a quarter of that reserved for private EL2 mappings. That's
pretty big.
We will use a bit more of the memory that is set aside for EL2 page
tables, but this shouldn't be a problem either.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Kalesh Singh <kaleshsingh@google.com>
Cc: Will Deacon <will@kernel.org>,
Quentin Perret <qperret@google.com>,
Fuad Tabba <tabba@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 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 <kvmarm@lists.cs.columbia.edu>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 2/8] KVM: arm64: Introduce pkvm_alloc_private_va_range()
Date: Thu, 03 Mar 2022 17:29:33 +0000 [thread overview]
Message-ID: <87r17j0wsi.wl-maz@kernel.org> (raw)
In-Reply-To: <CAC_TJvfTZP9+EKFFXQUeGOWJb=WK2Wkd53bPOX2gaz0Gh5o8OA@mail.gmail.com>
Hi Kalesh,
On Wed, 02 Mar 2022 17:24:53 +0000,
Kalesh Singh <kaleshsingh@google.com> wrote:
>
> On Tue, Mar 1, 2022 at 11:46 PM Marc Zyngier <maz@kernel.org> wrote:
> >
> > On Fri, 25 Feb 2022 03:34:47 +0000,
> > Kalesh Singh <kaleshsingh@google.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 v4:
> > > - Handle null ptr in pkvm_alloc_private_va_range() and replace
> > > IS_ERR_OR_NULL checks in callers with IS_ERR checks, per Fuad
> > > - Fix kernel-doc comments format, per Fuad
> > > - Format __pkvm_create_private_mapping() prototype args (< 80 col), per Fuad
> > >
> > > 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
> >
> > I probably badly expressed my earlier concern.
> >
> > Yes, an alignment is necessary. But how often do we want an alignment
> > that isn't naturally aligned to the size of the allocation (i.e. the
> > power of 2 >= the size of the allocation)? This is what the rest of
> > the kernel does (get_order() and co), and I thing we should follow
> > this.
>
> Hi Marc,
>
> Thanks for clarifying. I think making the alignment implicitly based
> on the size here will create unnecessary holes where PAGE_SIZE
> alignment would be ok and potentially overflow the private VA space
> earlier. Is it not a concern?
I don't think we should worry too much about this. Even when building
the kernel with a very small VA space (commonly 39 bits), we still
have a quarter of that reserved for private EL2 mappings. That's
pretty big.
We will use a bit more of the memory that is set aside for EL2 page
tables, but this shouldn't be a problem either.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Kalesh Singh <kaleshsingh@google.com>
Cc: Will Deacon <will@kernel.org>,
Quentin Perret <qperret@google.com>,
Fuad Tabba <tabba@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 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 <kvmarm@lists.cs.columbia.edu>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 2/8] KVM: arm64: Introduce pkvm_alloc_private_va_range()
Date: Thu, 03 Mar 2022 17:29:33 +0000 [thread overview]
Message-ID: <87r17j0wsi.wl-maz@kernel.org> (raw)
In-Reply-To: <CAC_TJvfTZP9+EKFFXQUeGOWJb=WK2Wkd53bPOX2gaz0Gh5o8OA@mail.gmail.com>
Hi Kalesh,
On Wed, 02 Mar 2022 17:24:53 +0000,
Kalesh Singh <kaleshsingh@google.com> wrote:
>
> On Tue, Mar 1, 2022 at 11:46 PM Marc Zyngier <maz@kernel.org> wrote:
> >
> > On Fri, 25 Feb 2022 03:34:47 +0000,
> > Kalesh Singh <kaleshsingh@google.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 v4:
> > > - Handle null ptr in pkvm_alloc_private_va_range() and replace
> > > IS_ERR_OR_NULL checks in callers with IS_ERR checks, per Fuad
> > > - Fix kernel-doc comments format, per Fuad
> > > - Format __pkvm_create_private_mapping() prototype args (< 80 col), per Fuad
> > >
> > > 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
> >
> > I probably badly expressed my earlier concern.
> >
> > Yes, an alignment is necessary. But how often do we want an alignment
> > that isn't naturally aligned to the size of the allocation (i.e. the
> > power of 2 >= the size of the allocation)? This is what the rest of
> > the kernel does (get_order() and co), and I thing we should follow
> > this.
>
> Hi Marc,
>
> Thanks for clarifying. I think making the alignment implicitly based
> on the size here will create unnecessary holes where PAGE_SIZE
> alignment would be ok and potentially overflow the private VA space
> earlier. Is it not a concern?
I don't think we should worry too much about this. Even when building
the kernel with a very small VA space (commonly 39 bits), we still
have a quarter of that reserved for private EL2 mappings. That's
pretty big.
We will use a bit more of the memory that is set aside for EL2 page
tables, but this shouldn't be a problem either.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2022-03-03 17:29 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-25 3:34 [PATCH v4 0/8] KVM: arm64: Hypervisor stack enhancements Kalesh Singh
2022-02-25 3:34 ` Kalesh Singh
2022-02-25 3:34 ` Kalesh Singh
2022-02-25 3:34 ` [PATCH v4 1/8] KVM: arm64: Introduce hyp_alloc_private_va_range() Kalesh Singh
2022-02-25 3:34 ` Kalesh Singh
2022-02-25 3:34 ` Kalesh Singh
2022-02-25 3:34 ` [PATCH v4 2/8] KVM: arm64: Introduce pkvm_alloc_private_va_range() Kalesh Singh
2022-02-25 3:34 ` Kalesh Singh
2022-02-25 3:34 ` Kalesh Singh
2022-03-02 7:46 ` Marc Zyngier
2022-03-02 7:46 ` Marc Zyngier
2022-03-02 7:46 ` Marc Zyngier
2022-03-02 17:24 ` Kalesh Singh
2022-03-02 17:24 ` Kalesh Singh
2022-03-02 17:24 ` Kalesh Singh
2022-03-03 17:29 ` Marc Zyngier [this message]
2022-03-03 17:29 ` Marc Zyngier
2022-03-03 17:29 ` Marc Zyngier
2022-03-03 17:45 ` Kalesh Singh
2022-03-03 17:45 ` Kalesh Singh
2022-03-03 17:45 ` Kalesh Singh
2022-02-25 3:34 ` [PATCH v4 3/8] KVM: arm64: Add guard pages for KVM nVHE hypervisor stack Kalesh Singh
2022-02-25 3:34 ` Kalesh Singh
2022-02-25 3:34 ` Kalesh Singh
2022-03-02 7:53 ` Marc Zyngier
2022-03-02 7:53 ` Marc Zyngier
2022-03-02 7:53 ` Marc Zyngier
2022-03-02 17:31 ` Kalesh Singh
2022-03-02 17:31 ` Kalesh Singh
2022-03-02 17:31 ` Kalesh Singh
2022-02-25 3:34 ` [PATCH v4 4/8] KVM: arm64: Add guard pages for pKVM (protected nVHE) " Kalesh Singh
2022-02-25 3:34 ` Kalesh Singh
2022-02-25 3:34 ` Kalesh Singh
2022-03-02 7:58 ` Marc Zyngier
2022-03-02 7:58 ` Marc Zyngier
2022-03-02 7:58 ` Marc Zyngier
2022-02-25 3:34 ` [PATCH v4 5/8] KVM: arm64: Detect and handle hypervisor stack overflows Kalesh Singh
2022-02-25 3:34 ` Kalesh Singh
2022-02-25 3:34 ` Kalesh Singh
2022-02-25 3:34 ` [PATCH v4 6/8] KVM: arm64: Add hypervisor overflow stack Kalesh Singh
2022-02-25 3:34 ` Kalesh Singh
2022-02-25 3:34 ` Kalesh Singh
2022-02-25 3:34 ` [PATCH v4 7/8] KVM: arm64: Unwind and dump nVHE HYP stacktrace Kalesh Singh
2022-02-25 3:34 ` Kalesh Singh
2022-02-25 3:34 ` Kalesh Singh
2022-02-25 3:34 ` [PATCH v4 8/8] KVM: arm64: Symbolize the nVHE HYP backtrace Kalesh Singh
2022-02-25 3:34 ` Kalesh Singh
2022-02-25 3:34 ` 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=87r17j0wsi.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=kaleshsingh@google.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=mhiramat@kernel.org \
--cc=pbonzini@redhat.com \
--cc=pcc@google.com \
--cc=surenb@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.