Hi Paolo,
On Thu, Apr 29, 2021 at 3:37 PM Jing Zhang wrote:
>
> This patchset provides a file descriptor for every VM and VCPU to read
> KVM statistics data in binary format.
> It is meant to provide a lightweight, flexible, scalable and efficient
> lock-free solution for user space telemetry
On Fri, May 07, 2021 at 10:04:14PM +0200, Andrew Jones wrote:
> Add a new command line option that allows the user to select a specific
> configuration, e.g. --config:sve will give the sve config. Also provide
> help text and the --help/-h options.
>
> Signed-off-by: Andrew Jones
> ---
>
On Mon, 10 May 2021 02:12:22 +0100,
Shaokun Zhang wrote:
>
> Hi Marc,
>
> On 2021/5/8 17:29, Marc Zyngier wrote:
> > On Sat, 08 May 2021 08:11:52 +0100,
> > Zhu Lingshan wrote:
> >>
> >> This reverts commit a979a6aa009f3c99689432e0cdb5402a4463fb88.
> >>
> >> The reverted commit may cause VM
Hi Marc,
On 5/10/21 9:49 AM, Marc Zyngier wrote:
> Hi Eric,
>
> On Sun, 09 May 2021 18:00:04 +0100,
> Auger Eric wrote:
>>
>> Hi,
>> On 5/7/21 1:02 PM, Marc Zyngier wrote:
>>> On Fri, 07 May 2021 10:58:23 +0100,
>>> Shaokun Zhang wrote:
Hi Marc,
Thanks for your quick reply.
Hi Marc,
On 5/5/21 8:03 PM, Marc Zyngier wrote:
> Hi Eric,
>
> On Tue, 04 May 2021 15:47:36 +0100,
> Auger Eric wrote:
>>
>> Hi David, Marc,
>>
>> On 8/5/20 7:56 PM, Marc Zyngier wrote:
>>> From: David Brazdil
>>>
>>> Add new folders arch/arm64/kvm/hyp/{vhe,nvhe} and Makefiles for building
Hi Eric,
On Sun, 09 May 2021 18:00:04 +0100,
Auger Eric wrote:
>
> Hi,
> On 5/7/21 1:02 PM, Marc Zyngier wrote:
> > On Fri, 07 May 2021 10:58:23 +0100,
> > Shaokun Zhang wrote:
> >>
> >> Hi Marc,
> >>
> >> Thanks for your quick reply.
> >>
> >> On 2021/5/7 17:03, Marc Zyngier wrote:
> >>> On
在 2021/5/8 下午3:11, Zhu Lingshan 写道:
This reverts commit a979a6aa009f3c99689432e0cdb5402a4463fb88.
The reverted commit may cause VM freeze on arm64 platform.
Because on arm64 platform, stop a consumer will suspend the VM,
the VM will freeze without a start consumer
Signed-off-by: Zhu Lingshan
在 2021/5/10 上午11:00, Zhu, Lingshan 写道:
On 5/10/2021 10:43 AM, Jason Wang wrote:
在 2021/5/8 下午3:11, Zhu Lingshan 写道:
This reverts commit a979a6aa009f3c99689432e0cdb5402a4463fb88.
The reverted commit may cause VM freeze on arm64 platform.
Because on arm64 platform, stop a consumer will
On 5/10/2021 10:43 AM, Jason Wang wrote:
在 2021/5/8 下午3:11, Zhu Lingshan 写道:
This reverts commit a979a6aa009f3c99689432e0cdb5402a4463fb88.
The reverted commit may cause VM freeze on arm64 platform.
Because on arm64 platform, stop a consumer will suspend the VM,
the VM will freeze without a
On 2021/5/9 13:59, Mike Rapoport wrote:
On Fri, May 07, 2021 at 08:34:52PM +0800, Kefeng Wang wrote:
On 2021/5/7 18:30, Mike Rapoport wrote:
On Fri, May 07, 2021 at 03:17:08PM +0800, Kefeng Wang wrote:
On 2021/5/6 20:47, Kefeng Wang wrote:
no, the CONFIG_ARM_LPAE is not set, and yes
On 5/10/2021 12:34 PM, Jason Wang wrote:
在 2021/5/10 上午11:00, Zhu, Lingshan 写道:
On 5/10/2021 10:43 AM, Jason Wang wrote:
在 2021/5/8 下午3:11, Zhu Lingshan 写道:
This reverts commit a979a6aa009f3c99689432e0cdb5402a4463fb88.
The reverted commit may cause VM freeze on arm64 platform.
Because
On Sun, 09 May 2021 14:07:45 +0100,
Zenghui Yu wrote:
>
> On 2021/5/6 22:29, Marc Zyngier wrote:
> > On Thu, 06 May 2021 12:43:26 +0100,
> > Zenghui Yu wrote:
> >>
> >> On 2021/5/6 14:33, Marc Zyngier wrote:
> >>> On Wed, 05 May 2021 17:46:51 +0100,
> >>> Marc Zyngier wrote:
>
> Hi
On 5/10/2021 3:09 PM, Zhu, Lingshan wrote:
On 5/10/2021 12:34 PM, Jason Wang wrote:
在 2021/5/10 上午11:00, Zhu, Lingshan 写道:
On 5/10/2021 10:43 AM, Jason Wang wrote:
在 2021/5/8 下午3:11, Zhu Lingshan 写道:
This reverts commit a979a6aa009f3c99689432e0cdb5402a4463fb88.
The reverted commit
As we we now entertain the possibility of FIQ being used on the host,
treat the signalling of a FIQ while running a guest as an IRQ,
causing an exit instead of a HYP panic.
Signed-off-by: Marc Zyngier
---
arch/arm64/kvm/hyp/hyp-entry.S | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
This is a new version of the series previously posted at [2], reworking
the vGIC and timer code to cope with the M1 braindead^Wamusing nature.
Hardly any change this time around, mostly rebased on top of upstream
now that the dependencies have made it in.
Tested with multiple concurrent VMs
The vGIC, as architected by ARM, allows a virtual interrupt to
trigger the deactivation of a physical interrupt. This allows
the following interrupt to be delivered without requiring an exit.
However, some implementations have choosen not to implement this,
meaning that we will need some
The vGIC advertising code is unsurprisingly very much tied to
the GIC implementations. However, we are about to extend the
support to lesser implementations.
Let's dissociate the vgic registration from the GIC code and
move it into KVM, where it makes a bit more sense. This also
allows us to mark
As it turns out, not all the interrupt controllers are able to
expose a vGIC maintenance interrupt as a distrete signal.
And to be fair, it doesn't really matter as all we require is
for *something* to kick us out of guest mode out way or another.
On systems that do not expose a maintenance
We already have the option to attach a callback to an interrupt
to retrieve its pending state. As we are planning to expand this
facility, move this callback into its own data structure.
This will limit the size of individual interrupts as the ops
structures can be shared across multiple
The CPUs in the Apple M1 SoC partially implement a virtual GICv3
CPU interface, although one that is incapable of HW deactivation
of interrupts.
Advertise the support to KVM.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-apple-aic.c | 8
1 file changed, 8 insertions(+)
diff
As we are about to add some more things to the timer IRQ
configuration, move this code out of the main timer init code
into its own set of functions.
No functional changes.
Signed-off-by: Marc Zyngier
---
arch/arm64/kvm/arch_timer.c | 61 ++---
1 file changed,
In order to deal with these systems that do not offer HW-based
deactivation of interrupts, let implement a SW-based approach:
- When the irq is queued into a LR, treat it as a pure virtual
interrupt and set the EOI flag in the LR.
- When the interrupt state is read back from the LR, force a
In order to deal with the lack of active state, we need to use
the mask/unmask primitives (after all, the active state is just an
additional mask on top of the normal one).
To avoid adding a bunch of ugly conditionals in the timer and vgic
code, let's use a timer-specific irqdomain to deal with
On 5/10/2021 6:00 PM, Marc Zyngier wrote:
On Mon, 10 May 2021 09:32:54 +0100,
"Zhu, Lingshan" wrote:
On 5/10/2021 3:09 PM, Zhu, Lingshan wrote:
On 5/10/2021 12:34 PM, Jason Wang wrote:
在 2021/5/10 上午11:00, Zhu, Lingshan 写道:
On 5/10/2021 10:43 AM, Jason Wang wrote:
在 2021/5/8 下午3:11,
In order to make it easy to call __adjust_pc() from the EL1 code
(in the case of nVHE), rename it to __kvm_adjust_pc() and move
it out of line.
No expected functional change.
Signed-off-by: Marc Zyngier
Cc: sta...@vger.kernel.org # 5.11
---
arch/arm64/include/asm/kvm_asm.h | 2 ++
We recently moved anything related to PC updates into the guest entry
code to help with the protected KVM effort. However, I missed a
critical point: userspace needs to be able to observe state changes
when the vcpu exits. Otherwise, live migration is a bit broken and
vcpu reset can fail (as
KVM currently updates PC (and the corresponding exception state)
using a two phase approach: first by setting a set of flags,
then by converting these flags into a state update when the vcpu
is about to enter the guest.
However, this creates a disconnect with userspace if the vcpu thread
returns
On Mon, 10 May 2021 09:29:47 +0100,
Auger Eric wrote:
>
> Hi Marc,
>
> On 5/10/21 9:49 AM, Marc Zyngier wrote:
> > Hi Eric,
> >
> > On Sun, 09 May 2021 18:00:04 +0100,
> > Auger Eric wrote:
> >>
> >> Hi,
> >> On 5/7/21 1:02 PM, Marc Zyngier wrote:
> >>> On Fri, 07 May 2021 10:58:23 +0100,
>
On Sat, 8 May 2021 15:11:52 +0800, Zhu Lingshan wrote:
> This reverts commit a979a6aa009f3c99689432e0cdb5402a4463fb88.
>
> The reverted commit may cause VM freeze on arm64 platform.
> Because on arm64 platform, stop a consumer will suspend the VM,
> the VM will freeze without a start consumer
On Mon, 10 May 2021 09:32:54 +0100,
"Zhu, Lingshan" wrote:
>
>
>
> On 5/10/2021 3:09 PM, Zhu, Lingshan wrote:
> >
> >
> > On 5/10/2021 12:34 PM, Jason Wang wrote:
> >>
> >> 在 2021/5/10 上午11:00, Zhu, Lingshan 写道:
> >>>
> >>>
> >>> On 5/10/2021 10:43 AM, Jason Wang wrote:
>
> 在
Hi Marc,
On 5/10/21 10:49 AM, Marc Zyngier wrote:
> In order to make it easy to call __adjust_pc() from the EL1 code
> (in the case of nVHE), rename it to __kvm_adjust_pc() and move
> it out of line.
>
> No expected functional change.
It does look to me like they're functionally identical. Minor
Hi Marc,
On 5/10/21 10:49 AM, Marc Zyngier wrote:
> KVM currently updates PC (and the corresponding exception state)
> using a two phase approach: first by setting a set of flags,
> then by converting these flags into a state update when the vcpu
> is about to enter the guest.
>
> However, this
Hi Marc,
On 5/10/21 4:04 PM, Marc Zyngier wrote:
> On Mon, 10 May 2021 15:55:28 +0100,
> Alexandru Elisei wrote:
>> Hi Marc,
>>
>> On 5/10/21 10:49 AM, Marc Zyngier wrote:
>>> KVM currently updates PC (and the corresponding exception state)
>>> using a two phase approach: first by setting a set
On Mon, 10 May 2021 15:55:28 +0100,
Alexandru Elisei wrote:
>
> Hi Marc,
>
> On 5/10/21 10:49 AM, Marc Zyngier wrote:
> > KVM currently updates PC (and the corresponding exception state)
> > using a two phase approach: first by setting a set of flags,
> > then by converting these flags into a
On Mon, 10 May 2021 15:55:16 +0100,
Alexandru Elisei wrote:
>
> Hi Marc,
>
> On 5/10/21 10:49 AM, Marc Zyngier wrote:
> > In order to make it easy to call __adjust_pc() from the EL1 code
> > (in the case of nVHE), rename it to __kvm_adjust_pc() and move
> > it out of line.
> >
> > No expected
When supporting nested virtualization a guest hypervisor executing TLBI
instructions must be trapped and emulated by the host hypervisor,
because the guest hypervisor can only affect physical TLB entries
relating to its own execution environment (virtual EL2 in EL1) but not
to the nested guests as
When mapping a page in a shadow stage-2, special care must be
taken not to be more permissive than the guest is (writable or
readable page when the guest hasn't set that permission).
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_nested.h | 15 +++
arch/arm64/kvm/mmu.c
If running a NV guest on an ARMv8.4-NV capable system, let's
allocate an additional page that will be used by the hypervisor
to fulfill system register accesses.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_host.h | 3 ++-
arch/arm64/kvm/nested.c | 10 ++
From: Jintack Lim
VMs used to execute hvc #0 for the psci call if EL3 is not implemented.
However, when we come to provide the virtual EL2 mode to the VM, the
host OS inside the VM calls kvm_call_hyp() which is also hvc #0. So,
it's hard to differentiate between them from the host hypervisor's
Since we're (almost) feature complete, let's allow userspace to
request KVM_ARM_VCPU_NESTED_VIRT by bumping the KVM_VCPU_MAX_FEATURES
up. We also now advertise the feature to userspace with a new capability.
It's going to be great...
Signed-off-by: Marc Zyngier
---
In order to be able to make S2 TLB invalidations more performant on NV,
let's use a scheme derived from the ARMv8.4 TTL extension.
If bits [56:55] in the descriptor are non-zero, they indicate a level
which can be used as an invalidation range.
Signed-off-by: Marc Zyngier
---
From: Christoffer Dall
Should the guest hypervisor use the HW bit in the LRs, we need to
emulate the deactivation from the L2 guest into the L1 distributor
emulation, which is handled by L0.
It's all good fun.
Signed-off-by: Christoffer Dall
Signed-off-by: Marc Zyngier
---
From: Jintack Lim
Forward ELR_EL1, SPSR_EL1 and VBAR_EL1 traps to the virtual EL2 if the
virtual HCR_EL2.NV bit is set.
This is for recursive nested virtualization.
Signed-off-by: Jintack Lim
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_arm.h | 1 +
arch/arm64/kvm/sys_regs.c
From: Christoffer Dall
So far we were flushing almost the entire universe whenever a VM would
load/unload the SCTLR_EL1 and the two versions of that register had
different MMU enabled settings. This turned out to be so slow that it
prevented forward progress for a nested VM, because a scheduler
We don't want to expose complicated features to guests until we have
a good grasp on the basic CPU emulation. So let's pretend that RAS,
doesn't exist in a nested guest. We already hide the feature bits,
let's now make sure VDISR_EL1 will UNDEF.
Signed-off-by: Marc Zyngier
---
From: Jintack Lim
We enable nested virtualization by setting the HCR NV and NV1 bit.
When the virtual E2H bit is set, we can support EL2 register accesses
via EL1 registers from the virtual EL2 by doing trap-and-emulate. A
better alternative, however, is to allow the virtual EL2 to access EL2
When we take a maintenance interrupt, we need to decide whether
it is generated on an action from the guest, or if it is something
that needs to be forwarded to the guest hypervisor.
Signed-off-by: Marc Zyngier
---
arch/arm64/kvm/vgic/vgic-init.c | 30
From: Jintack Lim
With HCR_EL2.NV bit set, accesses to EL12 registers in the virtual EL2
trap to EL2. Handle those traps just like we do for EL1 registers.
One exception is CNTKCTL_EL12. We don't trap on CNTKCTL_EL1 for non-VHE
virtual EL2 because we don't have to. However, accessing
VNCR_EL2 points to a page containing a number of system registers
accessed by a guest hypervisor when ARMv8.4-NV is enabled.
Let's document the offsets in that page, as we are going to use
this layout.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/vncr_mapping.h | 73
From: Christoffer Dall
Emulating the ARMv8.4-NV timers is a bit odd, as the timers can
be reconfigured behind our back without the hypervisor even
noticing. In the VHE case, that's an actual regression in the
architecture...
Signed-off-by: Christoffer Dall
Signed-off-by: Marc Zyngier
---
From: Jintack Lim
When HCR.NV bit is set, execution of the EL2 translation regime address
aranslation instructions and TLB maintenance instructions are trapped to
EL2. In addition, execution of the EL1 translation regime address
aranslation instructions and TLB maintenance instructions that are
From: Christoffer Dall
Adding tracepoints to be able to peek into the shadow LRs used when
running a guest guest.
Signed-off-by: Christoffer Dall
Signed-off-by: Marc Zyngier
---
arch/arm64/kvm/vgic/vgic-nested-trace.h | 137
arch/arm64/kvm/vgic/vgic-v3-nested.c|
From: Jintack Lim
When entering a nested VM, we set up the hypervisor control interface
based on what the guest hypervisor has set. Especially, we investigate
each list register written by the guest hypervisor whether HW bit is
set. If so, we translate hw irq number from the guest's point of
If we are faulting on a shadow stage 2 translation, we first walk the
guest hypervisor's stage 2 page table to see if it has a mapping. If
not, we inject a stage 2 page fault to the virtual EL2. Otherwise, we
create a mapping in the shadow stage 2 page table.
Note that we have to deal with two
Add Stage-2 mmu data structures for virtual EL2 and for nested guests.
We don't yet populate shadow Stage-2 page tables, but we now have a
framework for getting to a shadow Stage-2 pgd.
We allocate twice the number of vcpus as Stage-2 mmu structures because
that's sufficient for each vcpu running
From: Jintack Lim
Forward the EL1 virtual memory register traps to the virtual EL2 if they
are not coming from the virtual EL2 and the virtual HCR_EL2.TVM or TRVM
bit is set.
This is for recursive nested virtualization.
Signed-off-by: Jintack Lim
Signed-off-by: Marc Zyngier
---
From: Jintack Lim
Forward exceptions due to WFI or WFE instructions to the virtual EL2 if
they are not coming from the virtual EL2 and virtual HCR_EL2.TWX is set.
Signed-off-by: Jintack Lim
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_nested.h | 2 ++
arch/arm64/kvm/Makefile
As there is a number of features that we either can't support,
or don't want to support right away with NV, let's add some
basic filtering so that we don't advertize silly things to the
EL2 guest.
Whilst we are at it, avertize ARMv8.4-TTL as well as ARMv8.5-GTG.
Signed-off-by: Marc Zyngier
---
From: Jintack Lim
For the same reason we trap virtual memory register accesses in virtual
EL2, we trap CPACR_EL1 access too; We allow the virtual EL2 mode to
access EL1 system register state instead of the virtual EL2 one.
Signed-off-by: Jintack Lim
Signed-off-by: Marc Zyngier
---
From: Christoffer Dall
When a guest hypervisor running virtual EL2 in EL1 executes an ERET
instruction, we will have set HCR_EL2.NV which traps ERET to EL2, so
that we can emulate the exception return in software.
Signed-off-by: Christoffer Dall
Signed-off-by: Marc Zyngier
---
From: Jintack Lim
This introduces a function prototype to determine if we need to forward
system instruction traps to the virtual EL2. The implementation of
forward_trap functions for each system instruction will be added in
later patches.
Signed-off-by: Jintack Lim
Signed-off-by: Marc Zyngier
Whenever we need to restore the guest's system registers to the CPU, we
now need to take care of the EL2 system registers as well. Most of them
are accessed via traps only, but some have an immediate effect and also
a guest running in VHE mode would expect them to be accessible via their
EL1
Support guest-provided information information to find out about
the range of required invalidation.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_nested.h | 1 +
arch/arm64/kvm/nested.c | 57 +
arch/arm64/kvm/sys_regs.c | 78
From: Jintack Lim
When supporting nested virtualization a guest hypervisor executing AT
instructions must be trapped and emulated by the host hypervisor,
because untrapped AT instructions operating on S1E1 will use the wrong
translation regieme (the one used to emulate virtual EL2 in EL1 instead
From: Jintack Lim
As we expect all PSCI calls from the L1 hypervisor to be performed
using SMC when nested virtualization is enabled, it is clear that
all HVC instruction from the VM (including from the virtual EL2)
are supposed to handled in the virtual EL2.
Forward these to EL2 as required.
KVM internally uses accessor functions when reading or writing the
guest's system registers. This takes care of accessing either the stored
copy or using the "live" EL1 system registers when the host uses VHE.
With the introduction of virtual EL2 we add a bunch of EL2 system
registers, which now
Some EL2 system registers immediately affect the current execution
of the system, so we need to use their respective EL1 counterparts.
For this we need to define a mapping between the two. In general,
this only affects non-VHE guest hypervisors, as VHE system registers
are compatible with the EL1
From: Christoffer Dall
Unmap/flush shadow stage 2 page tables for the nested VMs as well as the
stage 2 page table for the guest hypervisor.
Note: A bunch of the code in mmu.c relating to MMU notifiers is
currently dealt with in an extremely abrupt way, for example by clearing
out an entire
In order for vgic_v3_load_nested to be able to observe which timer
interrupts have the HW bit set for the current context, the timers
must have been loaded in the new mode and the right timer mapped
to their corresponding HW IRQs.
At the moment, we load the GIC first, meaning that timer
Add the required handling for EL2 and EL02 registers, as
well as EL1 registers used in the E2H context.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/sysreg.h | 6 +++
arch/arm64/kvm/sys_regs.c | 87 +
2 files changed, 93 insertions(+)
diff --git
From: Christoffer Dall
Based on the pseudo-code in the ARM ARM, implement a stage 2 software
page table walker.
Signed-off-by: Christoffer Dall
Signed-off-by: Jintack Lim
[maz: heavily reworked for future ARMv8.4-TTL support]
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/esr.h
The NV code relies on predicates such as is_hyp_ctxt() being
reliable. In turn, is_hyp_ctxt() relies on things like PSTATE
and the virtual HCR_EL2 being accurate.
But with ARMv8.4-NV removing trapping for a large part of the
EL2 system registers (among which HCR_EL2), we can't use such
trapping
The vgic nested state needs to be accessible from the VNCR page, and
thus needs to be part of the normal sysreg file. Let's move it there.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_host.h| 9 +++
arch/arm64/kvm/sys_regs.c| 53 +++--
Due to the way ARMv8.4-NV suppresses traps when accessing EL2
system registers, we can't track when the guest changes its
HCR_EL2.TGE setting. This means we always trap EL1 TLBIs,
even if they don't affect any guest.
This obviously has a huge impact on performance, as we handle
TLBI traps as a
When entering a nested guest (vgic_state_is_nested() == true),
special care must be taken *not* to make the vPE resident, as
these are interrupts targetting the L1 guest, and not any
nested guest.
By not making the vPE resident, we guarantee that the delivery
of an vLPI will result in a doorbell,
From: Jintack Lim
For the same reason we trap virtual memory register accesses at virtual
EL2, we need to trap SPSR_EL1, ELR_EL1 and VBAR_EL1 accesses. ARM v8.3
introduces the HCR_EL2.NV1 bit to be able to trap on those register
accesses in EL1. Do not set this bit until the whole nesting
From: Jintack Lim
Forward traps due to FP/ASIMD register accesses to the virtual EL2
if virtual CPTR_EL2.TFP is set (with HCR_EL2.E2H == 0) or
CPTR_EL2.FPEN is configure to do so (with HCR_EL2.E2h == 1).
Signed-off-by: Jintack Lim
Signed-off-by: Christoffer Dall
[maz: account for HCR_EL2.E2H
From: Christoffer Dall
When running in virtual EL2 mode, we actually run the hardware in EL1
and therefore have to use the EL1 registers to ensure correct operation.
By setting the HCR.TVM and HCR.TVRM we ensure that the virtual EL2 mode
doesn't shoot itself in the foot when setting up what it
As all the VNCR-capable system registers are nicely separated
from the rest of the crowd, let's set HCR_EL2.NV2 on and let
the ball rolling.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_arm.h | 1 +
arch/arm64/include/asm/kvm_emulate.h | 23 +--
HCR_EL2.E2H is nasty, as a flip of this bit completely changes the way
we deal with a lot of the state. So when the guest flips this bit
(sysregs are live), do the put/load dance so that we have a consistent
state.
Yes, this is slow. Don't do it.
Suggested-by: Alexandru Elisei
Signed-off-by:
With ARMv8.4-NV, registers that can be directly accessed in memory
by the guest have to live at architected offsets in a special page.
Let's annotate the sysreg enum to reflect the offset at which they
are in this page, whith a little twist:
If running on HW that doesn't have the ARMv8.4-NV
From: Christoffer Dall
We can no longer blindly copy the VCPU's PSTATE into SPSR_EL2 and return
to the guest and vice versa when taking an exception to the hypervisor,
because we emulate virtual EL2 in EL1 and therefore have to translate
the mode field from EL2 to EL1 and vice versa.
SPSR_EL2 needs special attention when running nested on ARMv8.3:
If taking an exception while running at vEL2 (actually EL1), the
HW will update the SPSR_EL1 register with the EL1 mode. We need
to track this in order to make sure that accesses to the virtual
view of SPSR_EL2 is correct.
To do
From: Jintack Lim
Forward traps due to HCR_EL2.NV bit to the virtual EL2 if they are not
coming from the virtual EL2 and the virtual HCR_EL2.NV bit is set.
In addition to EL2 register accesses, setting NV bit will also make EL12
register accesses trap to EL2. To emulate this for the virtual
From: Christoffer Dall
Emulating EL2 also means emulating the EL2 timers. To do so, we expand
our timer framework to deal with at most 4 timers. At any given time,
two timers are using the HW timers, and the two others are purely
emulated.
The role of deciding which is which at any given time
When entering a L2 guest (nested virt enabled, but not in hypervisor
context), we need to honor the traps the L1 guest has asked enabled.
For now, just OR the guest's HCR_EL2 into the host's. We may have to do
some filtering in the future though.
Signed-off-by: Marc Zyngier
---
The S2 page table code doesn't use the SW bits yet, but we are about
to need them to encode some guest Stage-2 information (its mapping size
in the form of the TTL encoding).
Propagate the SW bits specified by the caller, and store them into
the corresponding entry.
Signed-off-by: Marc Zyngier
Add the detection code for the ARMv8.4-NV feature.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/cpucaps.h| 1 +
arch/arm64/include/asm/kvm_nested.h | 6 ++
arch/arm64/kernel/cpufeature.c | 10 ++
3 files changed, 17 insertions(+)
diff --git
A significant part of the ARMv8.3-NV extension is to trap ERET
instructions so that the hypervisor gets a chance to switch
from a vEL2 L1 guest to an EL1 L2 guest.
But this also has the unfortunate consequence of trapping ERET
in unsuspecting circumstances, such as staying at vEL2 (interrupt
From: Andre Przywara
The VGIC maintenance IRQ signals various conditions about the LRs, when
the GIC's virtualization extension is used.
So far we didn't need it, but nested virtualization needs to know about
this interrupt, so add a userland interface to setup the IRQ number.
The architecture
On handling a debug trap, check whether we need to forward it to the
guest before handling it.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_nested.h | 2 ++
arch/arm64/kvm/emulate-nested.c | 9 +++--
arch/arm64/kvm/sys_regs.c | 3 +++
3 files changed, 12
Populate bits [56:55] of the leaf entry with the level provided
by the guest's S2 translation.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_nested.h | 8
arch/arm64/kvm/mmu.c| 6 ++
2 files changed, 14 insertions(+)
diff --git
On Mon, 10 May 2021 17:19:07 +0100,
Mark Rutland wrote:
>
> On Mon, May 10, 2021 at 02:48:18PM +0100, Marc Zyngier wrote:
> > As it turns out, not all the interrupt controllers are able to
> > expose a vGIC maintenance interrupt as a distrete signal.
> > And to be fair, it doesn't really matter
On Mon, May 10, 2021 at 02:48:18PM +0100, Marc Zyngier wrote:
> As it turns out, not all the interrupt controllers are able to
> expose a vGIC maintenance interrupt as a distrete signal.
> And to be fair, it doesn't really matter as all we require is
> for *something* to kick us out of guest mode
Here the bi-annual drop of the KVM/arm64 NV support code.
Not a lot has changed since [1], except for a discovery mechanism for
the EL2 support, some tidying up in the idreg emulation, dropping RMR
support, and a rebase on top of 5.13-rc1.
As usual, blame me for any bug, and nobody else.
It is
Add the minimal set of EL2 system registers to the vcpu context.
Nothing uses them just yet.
Reviewed-by: Andre Przywara
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_host.h | 33 ++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git
From: Christoffer Dall
When running a nested hypervisor we commonly have to figure out if
the VCPU mode is running in the context of a guest hypervisor or guest
guest, or just a normal guest.
Add convenient primitives for this.
Signed-off-by: Christoffer Dall
Signed-off-by: Marc Zyngier
---
From: Jintack Lim
ARM v8.3 introduces a new bit in the HCR_EL2, which is the NV bit. When
this bit is set, accessing EL2 registers in EL1 traps to EL2. In
addition, executing the following instructions in EL1 will trap to EL2:
tlbi, at, eret, and msr/mrs instructions to access SP_EL1. Most of
From: Christoffer Dall
The VMPIDR_EL2 and VPIDR_EL2 are architecturally UNKNOWN at reset, but
let's be nice to a guest hypervisor behaving foolishly and reset these
to something reasonable anyway.
Signed-off-by: Christoffer Dall
Signed-off-by: Marc Zyngier
---
arch/arm64/kvm/sys_regs.c | 25
From: Jintack Lim
Support injecting exceptions and performing exception returns to and
from virtual EL2. This must be done entirely in software except when
taking an exception from vEL0 to vEL2 when the virtual HCR_EL2.{E2H,TGE}
== {1,1} (a VHE guest hypervisor).
Signed-off-by: Jintack Lim
1 - 100 of 105 matches
Mail list logo
