Hi Nathan,
On 2020/7/23 10:51, Nathan Chancellor wrote:
For the future, is there an easy way to tell which type of system I am
using (nVHE or VHE)?
afaict the easiest way is looking at the kernel log and you will find
something like "{VHE,Hyp} mode initialized successfully". I can get the
Dear Valued Customer,
Thank you for your inquiry. Please let us know how we may assist you.
If you have a Renter’s policy, you can manage your policy online 24/7 at:
https://www.myassurantpolicy.com/
You have access to a range of service options including:
*
View/update policy information
With all nVHE per-CPU variables being part of the hyp per-CPU region,
mapping them individual is not necessary any longer. They are mapped to hyp
as part of the overall per-CPU region.
Signed-off-by: David Brazdil
---
arch/arm64/include/asm/kvm_mmu.h | 25 +++--
Defining a per-CPU variable in hyp/nvhe will result in its name being prefixed
with __kvm_nvhe_. Add helpers for declaring these variables in kernel proper
and accessing them with this_cpu_ptr and per_cpu_ptr.
Signed-off-by: David Brazdil
---
arch/arm64/include/asm/kvm_asm.h | 25
Introduce '.hyp.data..percpu' as part of ongoing effort to make nVHE
hyp code self-contained and independent of the rest of the kernel.
The series builds on top of the "Split off nVHE hyp code" series which
used objcopy to rename '.text' to '.hyp.text' and prefix all ELF
symbols with '__kvm_nvhe'
this_cpu_ptr is meant for use in kernel proper because it selects between
TPIDR_EL1/2 based on nVHE/VHE. __hyp_this_cpu_ptr was used in hyp to always
select TPIDR_EL2. Unify all users behind this_cpu_ptr and friends by
selecting _EL2 register under __KVM_NVHE_HYPERVISOR__.
Under
Hyp keeps track of which cores require SSBD callback by accessing a
kernel-proper global variable. Create an nVHE symbol of the same name
and copy the value from kernel proper to nVHE at KVM init time.
Done in preparation for separating percpu memory owned by kernel
proper and nVHE.
The hyp_adr/ldr_this_cpu helpers were introduced for use in hyp code because
they always needed to use TPIDR_EL2 for base, while adr/ldr_this_cpu from
kernel proper would select between TPIDR_EL2 and _EL1 based on VHE/nVHE.
Simplify this now that the nVHE hyp mode case can be handled using the
In preparation for unmapping hyp pages from host stage-2, allocate/free hyp
stack using new helpers which automatically mark the pages reserved.
Signed-off-by: David Brazdil
---
arch/arm64/kvm/arm.c | 49 ++--
1 file changed, 47 insertions(+), 2
Host CPU context is stored in a global per-cpu variable `kvm_host_data`.
In preparation for introducing independent per-CPU region for nVHE hyp,
create two separate instances of `kvm_host_data`, one for VHE and one
for nVHE.
Signed-off-by: David Brazdil
---
arch/arm64/include/asm/kvm_host.h | 2
Add hyp percpu section to linker script and rename the corresponding ELF
sections of hyp/nvhe object files. This moves all nVHE-specific percpu
variables to the new hyp percpu section.
Allocate sufficient amount of memory for all percpu hyp regions at global KVM
init time, and create
Modify generic linker script macros to generate section/symbol names for
percpu area using overridable macros. No functional changes.
This will allow arm64 linker script to define a second KVM-specific percpu
data section using the generic PERCPU_SECTION macro.
Signed-off-by: David Brazdil
---
Hey Will,
On Wednesday 22 Jul 2020 at 14:15:10 (+0100), Will Deacon wrote:
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 8c0035cab6b6..69dc36d1d486 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1326,7 +1326,7 @@ static bool
On Wed, Jul 22, 2020 at 05:36:34PM +0100, Marc Zyngier wrote:
> On 2020-07-22 17:24, Dave Martin wrote:
> >On Mon, Jul 13, 2020 at 10:05:01PM +0100, Andrew Scull wrote:
> >>The aim is to keep management of the flags in the host and out of hyp
> >>where possible. I find this makes it easier to
On 2020-07-22 17:24, Dave Martin wrote:
On Mon, Jul 13, 2020 at 10:05:01PM +0100, Andrew Scull wrote:
The aim is to keep management of the flags in the host and out of hyp
where possible. I find this makes it easier to understand how the
flags
are used as the responsibilities are clearly
On Mon, Jul 13, 2020 at 10:05:04PM +0100, Andrew Scull wrote:
vv Nit: Message body doesn't say what changed _or_ why. See comments on
patch 2.
> The task state can be checked by the host and the vcpu flags updated
> before calling into hyp. Hyp simply acts on the state provided to it by
> the
On Mon, Jul 13, 2020 at 10:05:01PM +0100, Andrew Scull wrote:
> The aim is to keep management of the flags in the host and out of hyp
> where possible. I find this makes it easier to understand how the flags
> are used as the responsibilities are clearly divided.
>
> The series applies on top of
On Mon, Jul 13, 2020 at 10:05:05PM +0100, Andrew Scull wrote:
Familiar nits about commit message and Subject line.
> Since hyp now doesn't access the host task's thread flags, there's no
> need to map them up to hyp.
>
> Signed-off-by: Andrew Scull
With a reworked commit message:
On Mon, Jul 13, 2020 at 10:05:02PM +0100, Andrew Scull wrote:
> 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
On Mon, Jul 13, 2020 at 10:05:03PM +0100, Andrew Scull wrote:
> If the system doesn't support FPSIMD features then the flags must never
Mustn't they? Why not? I think the flags are currently ignored in this
case, which is just as good.
I'm not disagreeing with the change here; I just want to
So far, vcpu_has_ptrauth() is implemented in terms of system_supports_*_auth()
calls, which are declared "inline". In some specific conditions (clang
and SCS), the "inline" very much turns into an "out of line", which
leads to a fireworks when this predicate is evaluated on a non-VHE
system (right
If a stage-2 page-table contains an executable, read-only mapping at the
pte level (e.g. due to dirty logging being enabled), a subsequent write
fault to the same page which tries to install a larger block mapping
(e.g. due to dirty logging having been disabled) will erroneously inherit
the exec
22 matches
Mail list logo
