From: Quentin Perret <qperret@google.com>
To: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
devicetree@vger.kernel.org,
Android Kernel Team <kernel-team@android.com>,
Frank Rowand <frowand.list@gmail.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
android-kvm@google.com, Catalin Marinas <catalin.marinas@arm.com>,
Fuad Tabba <tabba@google.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
James Morse <james.morse@arm.com>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
Marc Zyngier <maz@kernel.org>,
David Brazdil <dbrazdil@google.com>,
Will Deacon <will@kernel.org>,
"open list:KERNEL VIRTUAL MACHINE FOR ARM64 \(KVM/arm64\)"
<kvmarm@lists.cs.columbia.edu>,
Julien Thierry <julien.thierry.kdev@gmail.com>
Subject: Re: [RFC PATCH v2 15/26] of/fdt: Introduce early_init_dt_add_memory_hyp()
Date: Tue, 12 Jan 2021 09:51:51 +0000 [thread overview]
Message-ID: <X/1xN2UxiUxkzAiN@google.com> (raw)
In-Reply-To: <CAL_JsqLmzFWmTc=6JSRMofSEVRx9GCrwGxEsYog9dC16EMGdvQ@mail.gmail.com>
On Monday 11 Jan 2021 at 08:45:10 (-0600), Rob Herring wrote:
> On Fri, Jan 8, 2021 at 6:16 AM Quentin Perret <qperret@google.com> wrote:
> >
> > Introduce early_init_dt_add_memory_hyp() to allow KVM to conserve a copy
> > of the memory regions parsed from DT. This will be needed in the context
> > of the protected nVHE feature of KVM/arm64 where the code running at EL2
> > will be cleanly separated from the host kernel during boot, and will
> > need its own representation of memory.
>
> What happened to doing this with memblock?
I gave it a go, but as mentioned in v1, I ran into issues for nomap
regions. I want the hypervisor to know about these memory regions (it's
possible some of those will be given to protected guests for instance)
but these seem to be entirely removed from the memblocks when using DT:
https://elixir.bootlin.com/linux/latest/source/drivers/of/fdt.c#L1153
EFI appears to do things differently, though, as it 'just' uses
memblock_mark_nomap() instead of actively removing the memblock. And that
means I could actually use the memblock API for EFI, but I'd rather
have a common solution. I tried to understand why things are done
differently but couldn't find an answer and kept things simple and
working for now.
Is there a good reason for not using memblock_mark_nomap() with DT? If
not, I'm happy to try that.
Thanks,
Quentin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-01-12 9:56 UTC|newest]
Thread overview: 97+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-08 12:14 [RFC PATCH v2 00/26] KVM/arm64: A stage 2 for the host Quentin Perret
2021-01-08 12:14 ` [RFC PATCH v2 01/26] arm64: lib: Annotate {clear, copy}_page() as position-independent Quentin Perret
2021-01-08 12:15 ` [RFC PATCH v2 02/26] KVM: arm64: Link position-independent string routines into .hyp.text Quentin Perret
2021-01-08 12:15 ` [RFC PATCH v2 03/26] arm64: kvm: Add standalone ticket spinlock implementation for use at hyp Quentin Perret
2021-02-01 17:28 ` Will Deacon
2021-02-01 17:40 ` Quentin Perret
2021-01-08 12:15 ` [RFC PATCH v2 04/26] KVM: arm64: Initialize kvm_nvhe_init_params early Quentin Perret
2021-02-01 17:41 ` Will Deacon
2021-01-08 12:15 ` [RFC PATCH v2 05/26] KVM: arm64: Avoid free_page() in page-table allocator Quentin Perret
2021-02-01 17:46 ` Will Deacon
2021-01-08 12:15 ` [RFC PATCH v2 06/26] KVM: arm64: Factor memory allocation out of pgtable.c Quentin Perret
2021-02-01 18:16 ` Will Deacon
2021-02-01 18:32 ` Quentin Perret
2021-02-01 18:39 ` Will Deacon
2021-01-08 12:15 ` [RFC PATCH v2 07/26] KVM: arm64: Introduce a BSS section for use at Hyp Quentin Perret
2021-02-01 18:32 ` Will Deacon
2021-01-08 12:15 ` [RFC PATCH v2 08/26] KVM: arm64: Make kvm_call_hyp() a function call " Quentin Perret
2021-02-01 18:41 ` Will Deacon
2021-01-08 12:15 ` [RFC PATCH v2 09/26] KVM: arm64: Allow using kvm_nvhe_sym() in hyp code Quentin Perret
2021-02-01 18:43 ` Will Deacon
2021-01-08 12:15 ` [RFC PATCH v2 10/26] KVM: arm64: Introduce an early Hyp page allocator Quentin Perret
2021-02-01 19:00 ` Will Deacon
2021-02-02 9:44 ` Quentin Perret
2021-01-08 12:15 ` [RFC PATCH v2 11/26] KVM: arm64: Stub CONFIG_DEBUG_LIST at Hyp Quentin Perret
2021-02-01 19:06 ` Will Deacon
2021-02-02 9:57 ` Quentin Perret
2021-02-02 10:00 ` Will Deacon
2021-02-02 10:14 ` Quentin Perret
2021-01-08 12:15 ` [RFC PATCH v2 12/26] KVM: arm64: Introduce a Hyp buddy page allocator Quentin Perret
2021-02-02 18:13 ` Will Deacon
2021-02-03 18:33 ` Quentin Perret
2021-02-04 14:31 ` Will Deacon
2021-02-04 14:52 ` Quentin Perret
2021-02-04 17:48 ` Will Deacon
2021-02-04 18:01 ` Quentin Perret
2021-02-04 18:13 ` Will Deacon
2021-02-04 18:24 ` Quentin Perret
2021-02-04 18:19 ` Quentin Perret
2021-02-04 18:24 ` Will Deacon
2021-02-04 18:32 ` Quentin Perret
2021-01-08 12:15 ` [RFC PATCH v2 13/26] KVM: arm64: Enable access to sanitized CPU features at EL2 Quentin Perret
2021-01-13 11:33 ` Marc Zyngier
2021-01-13 14:23 ` Quentin Perret
2021-01-13 14:35 ` Quentin Perret
2021-01-13 17:27 ` Marc Zyngier
2021-01-13 18:28 ` Quentin Perret
2021-01-08 12:15 ` [RFC PATCH v2 14/26] KVM: arm64: Factor out vector address calculation Quentin Perret
2021-02-02 18:24 ` Will Deacon
2021-01-08 12:15 ` [RFC PATCH v2 15/26] of/fdt: Introduce early_init_dt_add_memory_hyp() Quentin Perret
2021-01-11 14:45 ` Rob Herring
2021-01-12 9:51 ` Quentin Perret [this message]
2021-01-12 14:10 ` Rob Herring
2021-01-12 14:26 ` Quentin Perret
2021-01-12 15:53 ` Rob Herring
2021-01-12 16:15 ` Quentin Perret
2021-01-12 16:45 ` Rob Herring
2021-01-12 16:50 ` Quentin Perret
2021-01-15 11:49 ` Quentin Perret
2021-01-08 12:15 ` [RFC PATCH v2 16/26] KVM: arm64: Prepare Hyp memory protection Quentin Perret
2021-02-03 14:37 ` Will Deacon
2021-02-04 10:47 ` Quentin Perret
2021-02-05 17:56 ` Will Deacon
2021-02-09 10:00 ` Quentin Perret
2021-02-09 12:23 ` Will Deacon
2021-02-19 18:32 ` Sean Christopherson
2021-02-22 11:04 ` Quentin Perret
2021-01-08 12:15 ` [RFC PATCH v2 17/26] KVM: arm64: Elevate Hyp mappings creation at EL2 Quentin Perret
2021-02-03 15:31 ` Will Deacon
2021-02-04 11:08 ` Quentin Perret
2021-02-05 18:01 ` Will Deacon
2021-01-08 12:15 ` [RFC PATCH v2 18/26] KVM: arm64: Use kvm_arch for stage 2 pgtable Quentin Perret
2021-02-03 15:34 ` Will Deacon
2021-01-08 12:15 ` [RFC PATCH v2 19/26] KVM: arm64: Use kvm_arch in kvm_s2_mmu Quentin Perret
2021-02-03 15:38 ` Will Deacon
2021-01-08 12:15 ` [RFC PATCH v2 20/26] KVM: arm64: Set host stage 2 using kvm_nvhe_init_params Quentin Perret
2021-02-03 16:05 ` Will Deacon
2021-01-08 12:15 ` [RFC PATCH v2 21/26] KVM: arm64: Refactor kvm_arm_setup_stage2() Quentin Perret
2021-02-03 15:53 ` Will Deacon
2021-02-04 14:07 ` Quentin Perret
2021-01-08 12:15 ` [RFC PATCH v2 22/26] KVM: arm64: Refactor __load_guest_stage2() Quentin Perret
2021-02-03 15:54 ` Will Deacon
2021-01-08 12:15 ` [RFC PATCH v2 23/26] KVM: arm64: Refactor __populate_fault_info() Quentin Perret
2021-02-03 15:58 ` Will Deacon
2021-02-04 14:18 ` Quentin Perret
2021-01-08 12:15 ` [RFC PATCH v2 24/26] KVM: arm64: Make memcache anonymous in pgtable allocator Quentin Perret
2021-02-03 15:59 ` Will Deacon
2021-02-04 14:24 ` Quentin Perret
2021-02-04 14:36 ` Will Deacon
2021-01-08 12:15 ` [RFC PATCH v2 25/26] KVM: arm64: Reserve memory for host stage 2 Quentin Perret
2021-01-08 12:15 ` [RFC PATCH v2 26/26] KVM: arm64: Wrap the host with a " Quentin Perret
2021-02-03 16:11 ` Will Deacon
2021-02-04 14:26 ` Quentin Perret
2021-02-04 14:37 ` Will Deacon
2021-02-17 16:27 ` [RFC PATCH v2 00/26] KVM/arm64: A stage 2 for the host Mate Toth-Pal
2021-02-17 17:24 ` Quentin Perret
2021-02-19 17:54 ` Sean Christopherson
2021-02-19 17:57 ` Quentin Perret
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=X/1xN2UxiUxkzAiN@google.com \
--to=qperret@google.com \
--cc=android-kvm@google.com \
--cc=catalin.marinas@arm.com \
--cc=dbrazdil@google.com \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=james.morse@arm.com \
--cc=julien.thierry.kdev@gmail.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=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=robh+dt@kernel.org \
--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).