On Thu, Sep 23, 2021 at 5:09 PM Sean Christopherson wrote:
>
> On Thu, Sep 23, 2021, Oliver Upton wrote:
> > While x86 does not require any additional setup to use the ucall
> > infrastructure, arm64 needs to set up the MMIO address used to signal a
> > ucall to userspace. rseq_test does not
On Thu, Sep 23, 2021, Oliver Upton wrote:
> While x86 does not require any additional setup to use the ucall
> infrastructure, arm64 needs to set up the MMIO address used to signal a
> ucall to userspace. rseq_test does not initialize the MMIO address,
> resulting in the test spinning
While x86 does not require any additional setup to use the ucall
infrastructure, arm64 needs to set up the MMIO address used to signal a
ucall to userspace. rseq_test does not initialize the MMIO address,
resulting in the test spinning indefinitely.
Fix the issue by calling ucall_init() during
On Thu, Sep 23, 2021 at 07:15:59PM +, Oliver Upton wrote:
> Certain VMMs/operators may wish to give their guests the ability to
> initiate a system suspend that could result in the VM being saved to
> persistent storage to be resumed at a later time. The PSCI v1.0
> specification describes an
Assert that the vCPU exits to userspace with KVM_SYSTEM_EVENT_SUSPEND if
it correctly executes the SYSTEM_SUSPEND PSCI call. Additionally, assert
that the guest PSCI call fails if preconditions are not met (more than 1
running vCPU).
Signed-off-by: Oliver Upton
---
Setting a vCPU's MP state to KVM_MP_STATE_STOPPED has the effect of
powering off the vCPU. Rather than using the vCPU init feature flag, use
the KVM_SET_MP_STATE ioctl to power off the target vCPU.
Signed-off-by: Oliver Upton
---
tools/testing/selftests/kvm/aarch64/psci_test.c | 13
The naming of the kvm_req_sleep function is confusing: the function
itself sleeps the vCPU, it does not request such an event. Rename the
function to make its purpose more clear.
No functional change intended.
Signed-off-by: Oliver Upton
---
arch/arm64/kvm/arm.c | 4 ++--
1 file changed, 2
In its implementation of the PSCI function, KVM needs to request that a
target vCPU resets before its next entry into the guest. Wrap the logic
for requesting a reset in a function for later use by other implemented
PSCI calls.
No functional change intended.
Signed-off-by: Oliver Upton
---
The PSCI and PV stolen time tests both need to make SMCCC calls within
the guest. Create a helper for making SMCCC calls and rework the
existing tests to use the library function.
Signed-off-by: Oliver Upton
---
.../testing/selftests/kvm/aarch64/psci_test.c | 25 ++-
Certain VMMs/operators may wish to give their guests the ability to
initiate a system suspend that could result in the VM being saved to
persistent storage to be resumed at a later time. The PSCI v1.0
specification describes an SMC, SYSTEM_SUSPEND, that allows a kernel to
request a system suspend.
The helper function does not need a pointer to the vCPU, as it only
consults a constant mask; drop the unused vcpu parameter.
Signed-off-by: Oliver Upton
---
arch/arm64/kvm/psci.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/psci.c
Split up the current test into several helpers that will be useful to
subsequent test cases added to the PSCI test suite.
Signed-off-by: Oliver Upton
---
.../testing/selftests/kvm/aarch64/psci_test.c | 68 ---
1 file changed, 45 insertions(+), 23 deletions(-)
diff --git
ARM DEN0022D 5.19 "SYSTEM_SUSPEND" describes a PSCI call that may be
used to request a system be suspended. This is optional for PSCI v1.0
and to date KVM has elected to not implement the call. However, a
VMM/operator may wish to provide their guests with the ability to
suspend/resume,
The only valid calling SMC calling convention from an AArch32 state is
SMC32. Disallow any PSCI function that sets the SMC64 function ID bit
when called from AArch32 rather than comparing against known SMC64 PSCI
functions.
Signed-off-by: Oliver Upton
---
arch/arm64/kvm/psci.c | 14
There are other interactions with PSCI worth testing; rename the PSCI
test to make it more generic.
No functional change intended.
Signed-off-by: Oliver Upton
---
tools/testing/selftests/kvm/.gitignore | 2 +-
tools/testing/selftests/kvm/Makefile
The emulation of WFI-like instructions (WFI, PSCI CPU_SUSPEND) is done
by calling kvm_vcpu_block() directly from the respective exit handlers.
A subsequent change to KVM will allow userspace to request a vCPU be
suspended on the next KVM_RUN, necessitating a deferral mechanism for
WFI emulation.
On Thu, Sep 23, 2021 at 1:32 AM Gavin Shan wrote:
>
> Hi Rob and Ard,
>
> On 9/22/21 9:05 PM, Ard Biesheuvel wrote:
> > On Tue, 21 Sept 2021 at 21:45, Rob Herring wrote:
> >> On Sun, Sep 5, 2021 at 11:16 PM Gavin Shan wrote:
> >>>
> >>> The empty memory nodes, where no memory resides in, are
Hi Suzuki,
Thank you for having a look!
On 9/22/21 11:11, Suzuki K Poulose wrote:
> On 25/08/2021 17:17, Alexandru Elisei wrote:
>> This is v4 of the SPE series posted at [1]. v2 can be found at [2], and the
>> original series at [3].
>>
>> Statistical Profiling Extension (SPE) is an optional
On Wed, Sep 22, 2021 at 11:53 AM Marc Zyngier wrote:
>
> On Wed, 22 Sep 2021 19:13:40 +0100,
> Sean Christopherson wrote:
>
> > Stepping back a bit, this is one piece of the larger issue of how to
> > modernize KVM for hyperscale usage. BPF and tracing are great when
> > the debugger has root
On Thu, 23 Sep 2021 14:02:11 +0100,
Will Deacon wrote:
>
> On Thu, Sep 23, 2021 at 01:56:21PM +0100, Marc Zyngier wrote:
> > On Thu, 23 Sep 2021 12:22:56 +0100,
> > Will Deacon wrote:
[...]
> > > static void handle_host_hcall(struct kvm_cpu_context *host_ctxt)
> > > {
> > >
On Thu, Sep 23, 2021 at 01:56:21PM +0100, Marc Zyngier wrote:
> On Thu, 23 Sep 2021 12:22:56 +0100,
> Will Deacon wrote:
> >
> > After pKVM has been 'finalised' using the __pkvm_prot_finalize hypercall,
> > the calling CPU will have a Stage-2 translation enabled to prevent access
> > to memory
On Thu, Sep 23, 2021 at 12:22:56PM +0100, Will Deacon wrote:
> After pKVM has been 'finalised' using the __pkvm_prot_finalize hypercall,
> the calling CPU will have a Stage-2 translation enabled to prevent access
> to memory pages owned by EL2.
>
> Although this forms a significant part of the
On Thu, 23 Sep 2021 12:22:56 +0100,
Will Deacon wrote:
>
> After pKVM has been 'finalised' using the __pkvm_prot_finalize hypercall,
> the calling CPU will have a Stage-2 translation enabled to prevent access
> to memory pages owned by EL2.
>
> Although this forms a significant part of the
On Thu, Sep 23, 2021 at 12:45:06PM +0100, Mark Rutland wrote:
> On Thu, Sep 23, 2021 at 12:22:52PM +0100, Will Deacon wrote:
> > When pKVM is enabled, the hypervisor code at EL2 and its data structures
> > are inaccessible to the host kernel and cannot be torn down or replaced
> > as this would
On Thu, 23 Sep 2021 12:22:51 +0100,
Will Deacon wrote:
>
> Hi folks,
>
> This series restricts the hypercalls available to the KVM host on arm64
> when pKVM is enabled so that it is not possible for the host to use them
> to replace the EL2 component with something else.
>
> This occurs in two
On Thu, Sep 23, 2021 at 12:22:52PM +0100, Will Deacon wrote:
> When pKVM is enabled, the hypervisor code at EL2 and its data structures
> are inaccessible to the host kernel and cannot be torn down or replaced
> as this would defeat the integrity properies which pKVM aims to provide.
>
After pKVM has been 'finalised' using the __pkvm_prot_finalize hypercall,
the calling CPU will have a Stage-2 translation enabled to prevent access
to memory pages owned by EL2.
Although this forms a significant part of the process to deprivilege the
host kernel, we also need to ensure that the
__pkvm_prot_finalize() completes the deprivilege of the host when pKVM
is in use by installing a stage-2 translation table for the calling CPU.
Issuing the hypercall multiple times for a given CPU makes little sense,
but in such a case just return early with -EPERM rather than go through
the
If the __pkvm_prot_finalize hypercall returns an error, we WARN but fail
to propagate the failure code back to kvm_arch_init().
Pass a pointer to a zero-initialised return variable so that failure
to finalise the pKVM protections on a host CPU can be reported back to
KVM.
Cc: Marc Zyngier
Cc:
The stub hypercalls provide mechanisms to reset and replace the EL2 code,
so uninstall them once pKVM has been initialised in order to ensure the
integrity of the hypervisor code.
To ensure pKVM initialisation remains functional, split cpu_hyp_reinit()
into two helper functions to separate usage
When pKVM is enabled, the hypervisor code at EL2 and its data structures
are inaccessible to the host kernel and cannot be torn down or replaced
as this would defeat the integrity properies which pKVM aims to provide.
Furthermore, the ABI between the host and EL2 is flexible and private to
Hi folks,
This series restricts the hypercalls available to the KVM host on arm64
when pKVM is enabled so that it is not possible for the host to use them
to replace the EL2 component with something else.
This occurs in two stages: when switching to the pKVM vectors, the stub
hypercalls are
On 23/09/21 09:45, Marc Zyngier wrote:
On Thu, 23 Sep 2021 07:36:21 +0100,
Paolo Bonzini wrote:
On 22/09/21 20:53, Marc Zyngier wrote:
I definitely regret adding the current KVM trace points, as they
don't show what I need, and I can't change them as they are ABI.
I disagree that they are
On Thu, 23 Sep 2021 07:36:21 +0100,
Paolo Bonzini wrote:
>
> On 22/09/21 20:53, Marc Zyngier wrote:
> > I definitely regret adding the current KVM trace points, as they
> > don't show what I need, and I can't change them as they are ABI.
>
> I disagree that they are ABI. And even if you don't
On 22/09/21 20:53, Marc Zyngier wrote:
I definitely regret adding the current KVM trace points, as they
don't show what I need, and I can't change them as they are ABI.
I disagree that they are ABI. And even if you don't want to change
them, you can always add parameters or remove them.
Hi Rob and Ard,
On 9/22/21 9:05 PM, Ard Biesheuvel wrote:
On Tue, 21 Sept 2021 at 21:45, Rob Herring wrote:
On Sun, Sep 5, 2021 at 11:16 PM Gavin Shan wrote:
The empty memory nodes, where no memory resides in, are allowed.
For these empty memory nodes, the 'len' of 'reg' property is zero.
36 matches
Mail list logo
