Proxying host's PSCI SMCs will require synchronizing CPU_ON/OFF/SUSPEND
calls based on the observed state of individual cores. Add a per-CPU enum
that tracks the power state of each core and initialize all CPUs online
at the point of KVM init to ON.
Signed-off-by: David Brazdil
---
All nVHE hyp code is currently executed as handlers of host's HVCs. This
will change as nVHE starts intercepting host's PSCI CPU_ON SMCs. The
newly booted CPU will need to initialize EL2 state and then enter the
host. Add __host_enter function that branches into the existing
host state-restoring
From: Will Deacon
We will soon need to synchronise multiple CPUs in the hyp text at EL2.
The qspinlock-based locking used by the host is overkill for this purpose
and relies on the kernel's "percpu" implementation for the MCS nodes.
Implement a simple ticket locking scheme based heavily on the
Add a handler of the CPU_ON PSCI call from host. When invoked, it
looks up the logical CPU ID corresponding to the provided MPIDR and
populates the state struct of the target CPU with the provided x0, pc.
It then calls CPU_ON itself, with an entry point in hyp that initializes
EL2 state before
Add a handler of the CPU_OFF PSCI host SMC trapped in KVM nVHE hyp code.
When invoked, it changes the recorded state of the core to OFF before
forwarding the call to EL3. If the call fails, it changes the state back
to ON and returns the error to the host.
Signed-off-by: David Brazdil
---
Small refactor so that nVHE's handle_trap uses a switch on the Exception
Class value of ESR_EL2 in preparation for adding a handler of SMC32/64.
Signed-off-by: David Brazdil
---
arch/arm64/kvm/hyp/nvhe/hyp-main.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git
When nVHE hyp starts interception host's PSCI CPU_ON SMCs, it will need
to install KVM on the newly booted CPU before returning to the host. Add
an entry point which expects the same kvm_nvhe_init_params struct as the
__kvm_hyp_init HVC in the CPU_ON context argument (x0).
The entry point
While nVHE KVM is installed, start trapping all host SMCs. By default,
these are simply forwarded to EL3, but PSCI SMCs are validated first.
Create new constant HCR_HOST_NVHE_STUB_FLAGS with the old set of HCR
flags to use before the nVHE vector is installed or when switching back
to stub vector.
With nVHE hyp code interception host's PSCI CPU_ON/OFF/SUSPEND SMCs,
from the host's perspective new CPUs start booting in EL1 while
previously they would have booted in EL2. The kernel logic which keeps
track of the mode CPUs were booted in needs to be adjusted to account
for this fact.
Add a
Add a handler of CPU_SUSPEND host PSCI SMCs. When invoked, it determines
whether the requested power state loses context, ie. whether it is
indistinguishable from a WHI or whether it is a deeper sleep state that
behaves like a CPU_OFF+CPU_ON.
If it's the former, it forwards the call to EL3 and
Add a host-initialized constant to KVM nVHE hyp code for converting
between EL2 linear map virtual addresses and physical addresses.
Also add `__hyp_pa` macro that performs the conversion.
Signed-off-by: David Brazdil
---
arch/arm64/kvm/arm.c | 15 +++
Add a handler of PSCI SMCs in nVHE hyp code. The handler is initialized
with the version used by the host's PSCI driver and the function IDs it
was configured with. If the SMC function ID matches one of the
configured PSCI calls (for v0.1) or falls into the PSCI function ID
range (for v0.2+), the
Forward the following PSCI SMCs issued by host to EL3 as they do not
require the hypervisor's intervention. This assumes that EL3 correctly
implements the PSCI specification.
Only function IDs implemented in Linux are included.
Where both 32-bit and 64-bit variants exist, it is assumed that the
KVM by default keeps the stub vector installed and installs the nVHE
vector only briefly for init and later on demand. Change this policy
to install the vector at init and then never uninstall it.
Signed-off-by: David Brazdil
---
arch/arm64/kvm/arm.c | 17 +
1 file changed, 13
In preparation for adding a CPU entry point in nVHE hyp code, extract
most of __do_hyp_init hypervisor initialization code into a common
helper function. This will be invoked by the entry point to install KVM
on the newly booted CPU.
Signed-off-by: David Brazdil
---
When KVM starts validating host's PSCI requests, it will need to map
MPIDR back to the CPU ID. To this end, copy cpu_logical_map into nVHE
hyp memory when KVM is initialized.
Only copy the information for CPUs that are online at the point of KVM
initialization so that KVM rejects CPUs whose
Add rules for renaming a .data ELF section in KVM nVHE object files to
.hyp.data, linking it into the kernel and mapping it in hyp at runtime.
Signed-off-by: David Brazdil
---
arch/arm64/include/asm/sections.h | 1 +
arch/arm64/kernel/vmlinux.lds.S | 10 ++
arch/arm64/kvm/arm.c
As we progress towards being able to keep guest state private to the
host running nVHE hypervisor, this series allows the hypervisor to
install itself on newly booted CPUs before the host is allowed to run
on them.
To this end, the hypervisor starts trapping host SMCs and intercepting
host's PSCI
The version of PSCI that the kernel should use to communicate with
firmware is typically obtained from probing PSCI_VERSION. However, that
doesn't work for PSCI v0.1 where the host gets the information from
DT/ACPI, or if PSCI is not supported / was disabled.
KVM's PSCI proxy for the host needs
When compiling with __KVM_NVHE_HYPERVISOR__ redefine per_cpu_offset() to
__hyp_per_cpu_offset() which looks up the base of the nVHE per-CPU
region of the given cpu and computes its offset from the
.hyp.data..percpu section.
This enables use of per_cpu_ptr() helpers in nVHE hyp code. Until now
KVM currently initializes MAIR_EL2 to the value of MAIR_EL1. In
preparation for initializing MAIR_EL2 before MAIR_EL1, move the constant
into a shared header file.
Signed-off-by: David Brazdil
---
arch/arm64/include/asm/memory.h | 13 +
arch/arm64/mm/proc.S| 13
Once we start initializing KVM on newly booted cores before the rest of
the kernel, parameters to __do_hyp_init will need to be provided by EL2
rather than EL1. At that point it will not be possible to pass its four
arguments directly because PSCI_CPU_ON only supports one context
argument.
Function IDs used by PSCI are configurable for v0.1 via DT/APCI. If the
host is using PSCI v0.1, KVM's PSCI proxy needs to use the same IDs.
Expose the array holding the information.
Signed-off-by: David Brazdil
---
drivers/firmware/psci/psci.c | 10 +-
include/linux/psci.h | 10
When the a CPU is booted in EL2, the kernel checks for VHE support and
initializes the CPU core accordingly. For nVHE it also installs the stub
vectors and drops down to EL1.
Once KVM gains the ability to boot cores without going through the
kernel entry point, it will need to initialize the CPU
Add handler of host SMCs in KVM nVHE trap handler. Forward all SMCs to
EL3 and propagate the result back to EL1. This is done in preparation
for validating host SMCs.
Signed-off-by: David Brazdil
---
arch/arm64/kvm/hyp/nvhe/hyp-main.c | 36 ++
1 file changed, 36
MAIR_EL2 is currently initialized to the value of MAIR_EL1, which itself
is set to a constant MAIR_EL1_SET.
Initialize MAIR_EL2 to the MAIR_EL1_SET constant directly in preparation
of allowing KVM to start CPU cores itself and not initializing itself
before ERETing to EL1. In that case, MAIR_EL2
KVM's PSCI proxy could probe the firmware to establish features
supported for CPU_SUSPEND, but since the kernel's PSCI driver already
does that, and other information about the driver is already exported,
export the value of psci_cpu_suspend_feature as well for convenience.
Signed-off-by: David
On Tue, Nov 03, 2020 at 02:52:44PM +0100, Andrew Jones wrote:
> On Tue, Nov 03, 2020 at 11:37:27AM +, Dave Martin wrote:
> > On Mon, Nov 02, 2020 at 07:50:34PM +0100, Andrew Jones wrote:
> > > 张东旭 reported a regression seen with CentOS
> > > when migrating from an old kernel to a new one. The
On Tue, Nov 03, 2020 at 02:46:40PM +0100, Andrew Jones wrote:
> On Tue, Nov 03, 2020 at 11:32:08AM +, Dave Martin wrote:
> > On Mon, Nov 02, 2020 at 07:50:37PM +0100, Andrew Jones wrote:
> > > The AA64ZFR0_EL1 accessors are just the general accessors with
> > > its visibility function
On Tue, Nov 03, 2020 at 02:38:36PM +0100, Andrew Jones wrote:
> On Tue, Nov 03, 2020 at 11:23:54AM +, Dave Martin wrote:
> > On Mon, Nov 02, 2020 at 07:50:36PM +0100, Andrew Jones wrote:
> > > The instruction encodings of ID registers are preallocated. Until an
> > > encoding is assigned a
On Tue, Nov 03, 2020 at 02:32:15PM +0100, Andrew Jones wrote:
> On Tue, Nov 03, 2020 at 11:18:19AM +, Dave Martin wrote:
> > On Mon, Nov 02, 2020 at 07:50:35PM +0100, Andrew Jones wrote:
> > > ID registers are RAZ until they've been allocated a purpose, but
> > > that doesn't mean they should
31 matches
Mail list logo
