[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <73efca41e7b955db4963ff182624107d@kernel.org>
Date: Thu, 30 Apr 2020 18:53:47 +0100
From: Marc Zyngier <maz@...nel.org>
To: David Brazdil <dbrazdil@...gle.com>
Cc: Catalin Marinas <catalin.marinas@....com>,
James Morse <james.morse@....com>,
Julien Thierry <julien.thierry.kdev@...il.com>,
Suzuki K Poulose <suzuki.poulose@....com>,
Will Deacon <will@...nel.org>, kvmarm@...ts.cs.columbia.edu,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/15] Split off nVHE hyp code
Hi David,
Thanks for posting this, looks quite interesting!
On 2020-04-30 15:48, David Brazdil wrote:
> Refactor files in arch/arm64/kvm/hyp to compile all code which runs in
> EL2
> under nVHE into separate object files from the rest of KVM. This is
> done in
> preparation for being able to unmap .hyp.text from EL1 but has other
> benefits,
> notably:
> * safe use of KASAN/UBSAN/GCOV instrumentation on VHE code,
> * cleaner HVC API,
> * no need for __hyp_text annotations.
>
> nVHE-specific code is moved to hyp/nvhe and compiled with custom build
> rules
> similar to those used by EFI stub. Shared source files are compiled
> under both
> VHE and nVHE build rules. Where a source file contained both VHE and
> nVHE code,
> it is split into a shared header file and two C source files. This is
> done one
> file per commit to make review easier.
Do you have any figure on how much bigger the final kernel becomes once
this
is applied? I guess I can find out pretty easily, but this is the kind
of thing
that would be useful to make part of your cover letter.
I'll try to review this shortly.
Thanks,
M.
Powered by blists - more mailing lists