On Wed, Apr 22, 2020 at 05:13:46PM +0100, Andrew Scull wrote:
> * From v1 <20200327143941.195626-1-asc...@google.com>:
> - Restored registers in VHE path
> - RFC: Remove trust in host
Woops, got a bit happy with my clipboard. That last point isn't included
here as it didn't seem totally
Errata 1165522, 1319367 and 1530923 each allow TLB entries to be
allocated as a result of a speculative AT instruction. In order to
avoid mandating VHE on certain affected CPUs, apply the workaround to
both the nVHE and the VHE case for all affected CPUs.
Signed-off-by: Andrew Scull
CC: Marc
From: Zenghui Yu
If we're going to fail out the vgic_add_lpi(), let's make sure the
allocated vgic_irq memory is also freed. Though it seems that both
cases are unlikely to fail.
Signed-off-by: Zenghui Yu
Signed-off-by: Marc Zyngier
Link:
From: Zenghui Yu
It's likely that the vcpu fails to handle all virtual interrupts if
userspace decides to destroy it, leaving the pending ones stay in the
ap_list. If the un-handled one is a LPI, its vgic_irq structure will
be eventually leaked because of an extra refcount increment in
When a guest tries to read the active state of its interrupts,
we currently just return whatever state we have in memory. This
means that if such an interrupt lives in a List Register on another
CPU, we fail to obsertve the latest active state for this interrupt.
In order to remedy this, stop all
There is no point in accessing the HW when writing to any of the
ISPENDR/ICPENDR registers from userspace, as only the guest should
be allowed to change the HW state.
Introduce new userspace-specific accessors that deal solely with
the virtual state. Note that the API differs from that of GICv3,
When deciding whether a guest has to be stopped we check whether this
is a private interrupt or not. Unfortunately, there's an off-by-one bug
here, and we fail to recognize a whole range of interrupts as being
global (GICv2 SPIs 32-63).
Fix the condition from > to be >=.
Cc:
There is no point in accessing the HW when writing to any of the
ISENABLER/ICENABLER registers from userspace, as only the guest
should be allowed to change the HW state.
Introduce new userspace-specific accessors that deal solely with
the virtual state.
Reported-by: James Morse
Tested-by:
Here's a few vgic fixes I've been piling on during the merge window,
plus a couple that Zenghui contributed, and which I added to the mix.
The first patch is a silly off-by-one bug in the ACTIVE handling code,
where we miss fail to stop the guest if writing to the first set of
GICv2 SPIs. Oopsie
On Wed, 22 Apr 2020 17:58:04 +0200
Christian Borntraeger wrote:
> On 22.04.20 15:45, Cornelia Huck wrote:
> > On Wed, 22 Apr 2020 20:58:04 +0800
> > Tianjia Zhang wrote:
> >
> >> In the current kvm version, 'kvm_run' has been included in the 'kvm_vcpu'
> >> structure. Earlier than historical
Hi James,
On 2020-04-22 16:55, James Morse wrote:
Hi Marc,
On 20/04/2020 11:03, Marc Zyngier wrote:
On Fri, 17 Apr 2020 17:48:34 +0100
James Morse wrote:
[...]
(but if user-space never actually does this, then we should do the
simplest thing)
Adding printk() to this combined patch and
On 22.04.20 15:45, Cornelia Huck wrote:
> On Wed, 22 Apr 2020 20:58:04 +0800
> Tianjia Zhang wrote:
>
>> In the current kvm version, 'kvm_run' has been included in the 'kvm_vcpu'
>> structure. Earlier than historical reasons, many kvm-related function
>
> s/Earlier than/For/ ?
>
>>
Hi Marc,
On 20/04/2020 11:03, Marc Zyngier wrote:
> On Fri, 17 Apr 2020 17:48:34 +0100
> James Morse wrote:
>> On 17/04/2020 13:41, Marc Zyngier wrote:
>>> On Fri, 17 Apr 2020 12:22:10 +0100 James Morse wrote:
>>>
On 17/04/2020 09:33, Marc Zyngier wrote:
> There is no point in
On 2020-04-22 16:22, Will Deacon wrote:
On Tue, Apr 21, 2020 at 10:17:07AM +0100, Will Deacon wrote:
Both kvm/{arm,handle_exit}.c include trace.h and attempt to
instantiate
the same tracepoints, resulting in failures at link-time:
| aarch64-linux-gnu-ld:
On Tue, Apr 21, 2020 at 10:17:07AM +0100, Will Deacon wrote:
> Both kvm/{arm,handle_exit}.c include trace.h and attempt to instantiate
> the same tracepoints, resulting in failures at link-time:
>
> | aarch64-linux-gnu-ld: arch/arm64/kvm/handle_exit.o:(__tracepoints+0x30):
> | multiple
On 04/22/2020 03:07 PM, Marc Zyngier wrote:
Hi Suzuki,
On 2020-04-22 14:40, Suzuki K Poulose wrote:
Hi Marc,
On 04/22/2020 01:00 PM, Marc Zyngier wrote:
With ARMv8.5-GTG, the hardware (or more likely a hypervisor) can
advertise the supported Stage-2 page sizes.
Let's check this at boot
Hi Suzuki,
On 2020-04-22 14:40, Suzuki K Poulose wrote:
Hi Marc,
On 04/22/2020 01:00 PM, Marc Zyngier wrote:
With ARMv8.5-GTG, the hardware (or more likely a hypervisor) can
advertise the supported Stage-2 page sizes.
Let's check this at boot time.
Signed-off-by: Marc Zyngier
---
Hi Suzuki,
On 2020-04-22 14:51, Suzuki K Poulose wrote:
Hi Marc,
On 04/22/2020 01:00 PM, Marc Zyngier wrote:
Having __load_guest_stage2 in kvm_hyp.h is quickly going to trigger
a circular include problem. In order to avoid this, let's move
it to kvm_mmu.h, where it will be a better fit
Hi Marc,
On 04/22/2020 01:00 PM, Marc Zyngier wrote:
Having __load_guest_stage2 in kvm_hyp.h is quickly going to trigger
a circular include problem. In order to avoid this, let's move
it to kvm_mmu.h, where it will be a better fit anyway.
In the process, drop the __hyp_text annotation, which
On Wed, 22 Apr 2020 20:58:04 +0800
Tianjia Zhang wrote:
> In the current kvm version, 'kvm_run' has been included in the 'kvm_vcpu'
> structure. Earlier than historical reasons, many kvm-related function
s/Earlier than/For/ ?
> parameters retain the 'kvm_run' and 'kvm_vcpu' parameters at the
Hi Marc,
On 04/22/2020 01:00 PM, Marc Zyngier wrote:
With ARMv8.5-GTG, the hardware (or more likely a hypervisor) can
advertise the supported Stage-2 page sizes.
Let's check this at boot time.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_host.h | 2 +-
In the current kvm version, 'kvm_run' has been included in the 'kvm_vcpu'
structure. Earlier than historical reasons, many kvm-related function
parameters retain the 'kvm_run' and 'kvm_vcpu' parameters at the same time.
This patch does a unified cleanup of these remaining redundant parameters.
In the current kvm version, 'kvm_run' has been included in the 'kvm_vcpu'
structure. Earlier than historical reasons, many kvm-related function
parameters retain the 'kvm_run' and 'kvm_vcpu' parameters at the same time.
This patch does a unified cleanup of these remaining redundant parameters.
In the current kvm version, 'kvm_run' has been included in the 'kvm_vcpu'
structure. Earlier than historical reasons, many kvm-related function
parameters retain the 'kvm_run' and 'kvm_vcpu' parameters at the same time.
This patch does a unified cleanup of these remaining redundant parameters.
In the current kvm version, 'kvm_run' has been included in the 'kvm_vcpu'
structure. Earlier than historical reasons, many kvm-related function
parameters retain the 'kvm_run' and 'kvm_vcpu' parameters at the same time.
This patch does a unified cleanup of these remaining redundant parameters.
In the current kvm version, 'kvm_run' has been included in the 'kvm_vcpu'
structure. Earlier than historical reasons, many kvm-related function
parameters retain the 'kvm_run' and 'kvm_vcpu' parameters at the same time.
This patch does a unified cleanup of these remaining redundant parameters.
In the current kvm version, 'kvm_run' has been included in the 'kvm_vcpu'
structure. Earlier than historical reasons, many kvm-related function
parameters retain the 'kvm_run' and 'kvm_vcpu' parameters at the same time.
This patch does a unified cleanup of these remaining redundant parameters.
In the current kvm version, 'kvm_run' has been included in the 'kvm_vcpu'
structure. Earlier than historical reasons, many kvm-related function
parameters retain the 'kvm_run' and 'kvm_vcpu' parameters at the same time.
This patch does a unified cleanup of these remaining redundant parameters.
The 'kvm_run' field already exists in the 'vcpu' structure, which
is the same structure as the 'kvm_run' in the 'vcpu_arch' and
should be deleted.
Signed-off-by: Tianjia Zhang
---
arch/powerpc/include/asm/kvm_host.h | 1 -
arch/powerpc/kvm/book3s_hv.c| 6 ++
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_host.h | 2 +-
arch/arm64/kvm/hyp/debug-sr.c | 4 +-
arch/arm64/kvm/hyp/switch.c | 11 ++-
arch/arm64/kvm/hyp/sysreg-sr.c| 114 +++---
4 files changed, 64 insertions(+), 67 deletions(-)
diff
Now that we have a wrapper for the sysreg accesses, let's use that
consistently.
Signed-off-by: Marc Zyngier
---
arch/arm64/kvm/fpsimd.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
index e329a36b2bee5..e503caff14d1e
Now that we have a wrapper for the sysreg accesses, let's use that
consistently.
Signed-off-by: Marc Zyngier
---
arch/arm64/kvm/hyp/debug-sr.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/kvm/hyp/debug-sr.c b/arch/arm64/kvm/hyp/debug-sr.c
index
As we're about to move SPSR_EL1 into the VNCR page, we need to
disassociate it from the rest of the 32bit cruft. Let's break
the array into individual fields.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_emulate.h | 4 ++--
arch/arm64/include/asm/kvm_host.h| 6 -
SPSR_EL1 being a VNCR-capable register with ARMv8.4-NV, move it to
the sysregs array and update the accessors.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_emulate.h | 4 ++--
arch/arm64/include/asm/kvm_host.h| 2 +-
arch/arm64/kvm/guest.c | 2 +-
SP_EL1 being a VNCR-capable register with ARMv8.4-NV, move it to the
system register array and update the accessors.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_host.h | 3 +--
arch/arm64/kvm/guest.c| 2 +-
arch/arm64/kvm/hyp/sysreg-sr.c| 4 ++--
3 files changed,
As ELR-EL1 is a VNCR-capable register with ARMv8.4-NV, let's move it to
the sys_regs array and repaint the accessors. While we're at it, let's
kill the now useless accessors used only on the fault injection path.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_emulate.h | 21
Move the timer gsisters to the sysreg file. This will further help when
they are directly changed by a nesting hypervisor in the VNCR page.
This requires moving the initialisation of the timer struct so that some
of the helpers (such as arch_timer_ctx_index) can work correctly at an
early stage.
We currently assume that an exception is delivered to EL1, always.
Once we emulate EL2, this no longer will be the case. To prepare
for this, add a target_mode parameter.
While we're at it, merge the computing of the target PC and PSTATE in
a single function that updates both PC and CPSR after
Now that we have a wrapper for the sysreg accesses, let's use that
consistently.
Signed-off-by: Marc Zyngier
---
arch/arm64/kvm/handle_exit.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
index
struct kvm_regs is used by userspace to indicate which register gets
accessed by the {GET,SET}_ONE_REG API. But as we're about to refactor
the layout of the in-kernel register structures, we need the kernel to
move away from it.
Let's make kvm_regs userspace only, and let the kernel map it to its
Our sysreg reset check has become a bit silly, as it only checks whether
a reset callback actually exists for a given sysreg entry, and apply the
method if available. Doing the check at each vcpu reset is pretty dumb,
as the tables never change. It is thus perfectly possible to do the same
checks
As we're about to become a bit more harsh when it comes to the lack of
reset callbacks, let's add the missing PMU reset handlers. Note that
these only cover *CLR registers that were always covered by their *SET
counterpart, so there is no semantic change here.
Signed-off-by: Marc Zyngier
---
In order to allow the disintegration of the per-vcpu sysreg array,
let's introduce a new helper (ctxt_sys_reg()) that returns the
in-memory copy of a system register, picked from a given context.
__vcpu_sys_reg() is rewritten to use this helper.
Signed-off-by: Marc Zyngier
---
Keeping empty structure as the vcpu state initializer is slightly
wasteful: we only want to set pstate, and zero everything else.
Just do that.
Signed-off-by: Marc Zyngier
---
arch/arm64/kvm/reset.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git
kvm_timer_sync_hwstate() has nothing to do with the timer HW state,
but more to do with the state of a userspace interrupt controller.
Change the suffix from _hwstate to_user, in keeping with the rest
of the code.
Signed-off-by: Marc Zyngier
---
include/kvm/arm_arch_timer.h | 2 +-
Extract the direct HW accessors for later reuse.
Signed-off-by: Marc Zyngier
---
arch/arm64/kvm/sys_regs.c | 135 ++
1 file changed, 78 insertions(+), 57 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index
In order to reduce the cost of TLB invalidation, the ARMv8.4 TTL
feature allows TLBs to be issued with a level allowing for quicker
invalidation.
Let's detect the feature for now. Further patches will implement
its actual usage.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/cpucaps.h
Add a level-hinted TLB invalidation helper that only gets used if
ARMv8.4-TTL gets detected.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/tlbflush.h | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm64/include/asm/tlbflush.h
Advertise bits [58:55] as reserved for SW in the S2 descriptors.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/pgtable-hwdef.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/include/asm/pgtable-hwdef.h
b/arch/arm64/include/asm/pgtable-hwdef.h
index
From: Christoffer Dall
If we move the used_lrs field to the version-specific cpu interface
structure, the following functions only operate on the struct
vgic_v3_cpu_if and not the full vcpu:
__vgic_v3_save_state
__vgic_v3_restore_state
__vgic_v3_activate_traps
__vgic_v3_deactivate_traps
From: Christoffer Dall
As we are about to reuse our stage 2 page table manipulation code for
shadow stage 2 page tables in the context of nested virtualization, we
are going to manage multiple stage 2 page tables for a single VM.
This requires some pretty invasive changes to our data
Since we always have a precide idea of the level we're dealing with
when invalidating TLBs, we can provide it to as a hint to our
invalidation helper.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/stage2_pgtable.h | 9 +
virt/kvm/arm/mmu.c | 27
Introduce a level hint to __kvm_tlb_flush_vmid_ipa. No functional
change.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_asm.h | 3 ++-
arch/arm64/kvm/hyp/tlb.c | 5 +++--
virt/kvm/arm/mmu.c | 2 +-
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git
Hi all,
In order not to repeat the 90+ patch series that resulted in a
deafening silence last time, I've extracted a smaller set of patches
that form the required dependencies that allow the rest of the 65 NV
patches to be added on top. Yes, it is that bad.
The one real feature here is support
With ARMv8.5-GTG, the hardware (or more likely a hypervisor) can
advertise the supported Stage-2 page sizes.
Let's check this at boot time.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_host.h | 2 +-
arch/arm64/include/asm/sysreg.h | 3 +++
arch/arm64/kernel/cpufeature.c|
Having __load_guest_stage2 in kvm_hyp.h is quickly going to trigger
a circular include problem. In order to avoid this, let's move
it to kvm_mmu.h, where it will be a better fit anyway.
In the process, drop the __hyp_text annotation, which doesn't help
as the function is marked as
On 2020-04-22 05:07, Davidlohr Bueso wrote:
The use of any sort of waitqueue (simple or regular) for
wait/waking vcpus has always been an overkill and semantically
wrong. Because this is per-vcpu (which is blocked) there is
only ever a single waiting vcpu, thus no need for any sort of
queue.
As
The use of any sort of waitqueue (simple or regular) for
wait/waking vcpus has always been an overkill and semantically
wrong. Because this is per-vcpu (which is blocked) there is
only ever a single waiting vcpu, thus no need for any sort of
queue.
As such, make use of the rcuwait primitive, with
On 22/04/20 06:07, Davidlohr Bueso wrote:
> The use of any sort of waitqueue (simple or regular) for
> wait/waking vcpus has always been an overkill and semantically
> wrong. Because this is per-vcpu (which is blocked) there is
> only ever a single waiting vcpu, thus no need for any sort of
>
59 matches
Mail list logo
