On Thu, Mar 4, 2021 at 11:15 AM Marc Zyngier wrote:
>
> On Thu, 04 Mar 2021 18:45:44 +,
> Sami Tolvanen wrote:
> >
> > allmodconfig + CONFIG_LTO_CLANG_THIN=y fails to build due to following
> > linker errors:
> >
> > ld.lld: error: irqbypass.c:(function __guest_enter: .text+0x21CC):
>
> I
allmodconfig + CONFIG_LTO_CLANG_THIN=y fails to build due to following
linker errors:
ld.lld: error: irqbypass.c:(function __guest_enter: .text+0x21CC):
relocation R_AARCH64_CONDBR19 out of range: 2031220 is not in
[-1048576, 1048575]; references hyp_panic
>>> defined in vmlinux.o
On Thu, 04 Mar 2021 21:25:41 +,
Sami Tolvanen wrote:
>
> On Thu, Mar 4, 2021 at 11:15 AM Marc Zyngier wrote:
> >
> > On Thu, 04 Mar 2021 18:45:44 +,
> > Sami Tolvanen wrote:
> > >
> > > allmodconfig + CONFIG_LTO_CLANG_THIN=y fails to build due to following
> > > linker errors:
> > >
>
On Tue, Mar 02, 2021 at 03:00:00PM +, Quentin Perret wrote:
> We will soon unmap the .hyp sections from the host stage 2 in Protected
> nVHE mode, which obvisouly works with at least page granularity, so make
> sure to align them correctly.
s/obvisouly/obviously/
>
> Signed-off-by: Quentin
On Tue, Mar 02, 2021 at 02:59:57PM +, Quentin Perret wrote:
> In order to ease its re-use in other code paths, refactor
> stage2_map_set_prot_attr() to not depend on a stage2_map_data struct.
> No functional change intended.
>
> Signed-off-by: Quentin Perret
> ---
>
On Tue, Mar 02, 2021 at 02:59:56PM +, Quentin Perret wrote:
> Once we start unmapping portions of memory from the host stage 2 (such
> as e.g. the hypervisor memory sections, or pages that belong to
> protected guests), we will need a way to track page ownership. And
> given that all mappings
On Tue, Mar 02, 2021 at 02:59:55PM +, Quentin Perret wrote:
> We will soon need to check if a Physical Address belongs to a memblock
> at EL2, so make sure to sort them so this can be done efficiently.
>
> Signed-off-by: Quentin Perret
> ---
> arch/arm64/kvm/hyp/reserved_mem.c | 19
On Thursday 04 Mar 2021 at 15:30:36 (+), Will Deacon wrote:
> On Tue, Mar 02, 2021 at 02:59:42PM +, Quentin Perret wrote:
> > +void *hyp_alloc_pages(struct hyp_pool *pool, unsigned int order)
> > +{
> > + unsigned int i = order;
> > + struct hyp_page *p;
> > +
> > +
On Tue, Mar 02, 2021 at 02:59:54PM +, Quentin Perret wrote:
> Extend the memory pool allocated for the hypervisor to include enough
> pages to map all of memory at page granularity for the host stage 2.
> While at it, also reserve some memory for device mappings.
>
> Signed-off-by: Quentin
On Tue, Mar 02, 2021 at 02:59:53PM +, Quentin Perret wrote:
> The current stage2 page-table allocator uses a memcache to get
> pre-allocated pages when it needs any. To allow re-using this code at
> EL2 which uses a concept of memory pools, make the memcache argument of
>
On Tue, Mar 02, 2021 at 02:59:52PM +, Quentin Perret wrote:
> Refactor __populate_fault_info() to introduce __get_fault_info() which
> will be used once the host is wrapped in a stage 2.
>
> Signed-off-by: Quentin Perret
> ---
> arch/arm64/kvm/hyp/include/hyp/switch.h | 37
On Tue, Mar 02, 2021 at 02:59:50PM +, Quentin Perret wrote:
> In order to re-use some of the stage 2 setup code at EL2, factor parts
> of kvm_arm_setup_stage2() out into separate functions.
>
> No functional change intended.
>
> Signed-off-by: Quentin Perret
> ---
>
On Tue, Mar 02, 2021 at 02:59:46PM +, Quentin Perret wrote:
> Previous commits have introduced infrastructure to enable the EL2 code
> to manage its own stage 1 mappings. However, this was preliminary work,
> and none of it is currently in use.
>
> Put all of this together by elevating the
On Thu, 04 Mar 2021 18:45:44 +,
Sami Tolvanen wrote:
>
> allmodconfig + CONFIG_LTO_CLANG_THIN=y fails to build due to following
> linker errors:
>
> ld.lld: error: irqbypass.c:(function __guest_enter: .text+0x21CC):
I assume this message is only an oddity, right? Because
__guest_enter()
Hi Quentin,
On Tue, Mar 02, 2021 at 02:59:45PM +, Quentin Perret wrote:
> When memory protection is enabled, the EL2 code needs the ability to
> create and manage its own page-table. To do so, introduce a new set of
> hypercalls to bootstrap a memory management system at EL2.
>
> This leads
Hi Shameer,
On Mon, Feb 22, 2021 at 03:53:37PM +, Shameer Kolothum wrote:
> If the SMMU supports BTM and the device belongs to NESTED domain
> with shared pasid table, we need to use the VMID allocated by the
> KVM for the s2 configuration. Hence, request a pinned VMID from KVM.
>
>
The run struct affects how hyp handles the guest's state so it needs to
be kept safe from the host in protected mode. Copy the relevant values
into hyp-private memory while running a vcpu to achieve this.
In the traditional, non-protected, mode, there's no need to protect the
values from the host
When returning to a user task from a vcpu, keep track of the vcpu state
being in registers so that the state can be reinstated on the next entry
if the registers still contain the vcpu's latest state.
This avoids the need to trap and restore in the case that the vcpu's
registers are still in
Move the clearing of KVM_ARM64_DEBUG_DIRTY from being one of the last
things hyp does before exiting to the host, to being one of the first
things the host does after hyp exits.
This means the host always manages the state of the bit and hyp simply
respects that in the context switch.
No
Rather than accessing struct kvm_vcpu_arch_run via the vcpu, pass it
explicitly as an argument where needed. This will allow a hyp-private
copy of the struct to be swapped in when running in protected mode.
Signed-off-by: Andrew Scull
---
arch/arm64/kvm/hyp/include/hyp/switch.h | 15
smp_procesor_id() works off of the cpu_number per-cpu variable. Create
an nVHE hyp version of cpu_number and initialize it to the same value as
the host when creating the hyp per-cpu regions.
Signed-off-by: Andrew Scull
---
arch/arm64/kvm/arm.c | 2 ++
Hyp no longer needs access to the host task's thread flags so remove the
corresponding hyp mapping.
Signed-off-by: Andrew Scull
Cc: Dave Martin
---
arch/arm64/include/asm/kvm_host.h | 2 --
arch/arm64/kvm/fpsimd.c | 11 +--
2 files changed, 1 insertion(+), 12 deletions(-)
Protected VM's FPSIMD state must not be exposed to the host. Since the
FPSIMD state is switched lazily, hyp must take precautions to prevent
leaks. Do this by trapping FP access to EL2 to lazily save a protected
guest's state and lazily restore the hosts's state.
This is a little ahead of its
Keep track of the cpu that a vcpu's FP state was last loaded onto. This
information is needed in order to tell whether a vcpu's latest FP state
is already loaded on a cpu to avoid unnecessary reloading.
The method follows the pattern used by thread_struct whereby an
fpsimd_cpu field is added and
This series build towards protecting of FPSIMD state in protected KVM.
Most of the series is refactoring to create separation between host and
hyp for when that is needed.
There was the need to track where a vcpu last loaded its FPSIMD state so
I've also made use of this to avoid needless
The FP flags on the vcpu are used as arguments to hyp and to track the
state as hyp runs. In protected mode, this sort of state needs to be
safe from meddling by the host. Begin the separation with the FP flags.
Since protected mode is only available for nVHE and nVHE does not yet
support SVE,
Check the task's state about FP in the host and update the vcpu flags
before calling into hyp. This keeps the synchronization symmetrical
around the call into hyp.
kvm_arch_vcpu_ctxsync_fp() is renamed to kvm_arch_vcpu_sync_fp_after_hyp()
so that its name can pair with the new
On Tue, Mar 02, 2021 at 02:59:42PM +, Quentin Perret wrote:
> When memory protection is enabled, the hyp code will require a basic
> form of memory management in order to allocate and free memory pages at
> EL2. This is needed for various use-cases, including the creation of hyp
> mappings or
On Sat, 27 Feb 2021 10:41:57 +
Alexandru Elisei wrote:
> Compute the dcache line size when doing dcache maintenance instead of using
> a global variable computed in setup(), which allows us to do dcache
> maintenance at any point in the boot process. This will be useful for
> running as an
On Tue, Mar 02, 2021 at 02:59:40PM +, Quentin Perret wrote:
> With nVHE, the host currently creates all stage 1 hypervisor mappings at
> EL1 during boot, installs them at EL2, and extends them as required
> (e.g. when creating a new VM). But in a world where the host is no
> longer trusted, it
On Tue, Mar 02, 2021 at 02:59:37PM +, Quentin Perret wrote:
> Currently, the hyp code cannot make full use of a bss, as the kernel
> section is mapped read-only.
>
> While this mapping could simply be changed to read-write, it would
> intermingle even more the hyp and kernel state than they
On Tue, Mar 02, 2021 at 02:59:36PM +, Quentin Perret wrote:
> In preparation for enabling the creation of page-tables at EL2, factor
> all memory allocation out of the page-table code, hence making it
> re-usable with any compatible memory allocator.
>
> No functional changes intended.
>
>
On Tue, Mar 02, 2021 at 02:59:34PM +, Quentin Perret wrote:
> Move the initialization of kvm_nvhe_init_params in a dedicated function
> that is run early, and only once during KVM init, rather than every time
> the KVM vectors are set and reset.
>
> This also opens the opportunity for the
Hi Eric,
在 2021/2/24 4:56, Eric Auger 写道:
Implement domain-selective, pasid selective and page-selective
IOTLB invalidations.
Signed-off-by: Eric Auger
---
v13 -> v14:
- Add domain invalidation
- do global inval when asid is not provided with addr
granularity
v7 -> v8:
- ASID based
On Wed, 3 Mar 2021 10:42:25 +0800, Jia He wrote:
> If the start addr is not aligned with the granule size of that level.
> loop step size should be adjusted to boundary instead of simple
> kvm_granual_size(level) increment. Otherwise, some mmu entries might miss
> the chance to be walked through.
On Thu, Mar 04, 2021 at 09:16:25AM +, Marc Zyngier wrote:
> On 2021-03-04 00:46, Justin He wrote:
> > > On Wed, Mar 03, 2021 at 07:07:37PM +, Marc Zyngier wrote:
> > > > From e0524b41a71e0f17d6dc8f197e421e677d584e72 Mon Sep 17 00:00:00 2001
> > > > From: Jia He
> > > > Date: Wed, 3 Mar
On 2021-03-04 00:46, Justin He wrote:
Hi Marc
-Original Message-
From: Will Deacon
Sent: Thursday, March 4, 2021 5:13 AM
To: Marc Zyngier
Cc: Justin He ; kvmarm@lists.cs.columbia.edu; James
Morse ; Julien Thierry
;
Suzuki Poulose ; Catalin Marinas
; Gavin Shan ; Yanan Wang
;
37 matches
Mail list logo
