g PUD hugepages
> at stage 2 - which are supported on arm64 but do not exist on arm.
>
> Signed-off-by: Punit Agrawal
> Cc: Christoffer Dall
> Cc: Marc Zyngier
> Cc: Russell King
> Cc: Catalin Marinas
> Cc: Will Deacon
Acked-by: Christoffer Dall
> ---
> arch/
the operations when we introduce
> PUD hugepages, let's share them across the different pagesizes.
>
> Signed-off-by: Punit Agrawal
> Cc: Christoffer Dall
> Cc: Marc Zyngier
> ---
> virt/kvm/arm/mmu.c | 36 +---
> 1 file changed, 21 in
e) which can be useful on cores that
> support mapping larger block sizes in the TLB entries.
>
> Signed-off-by: Punit Agrawal
> Cc: Christoffer Dall
> Cc: Marc Zyngier
> Cc: Russell King
> Cc: Catalin Marinas
> Cc: Will Deacon
> ---
> arch/arm/include/asm/kvm_mmu.h
it doesn't matter how we configure HCR_EL2.{API,APK}, so we don't
> bother setting them.
>
> This does not enable support for KVM guests, since KVM manages HCR_EL2
> itself when running VMs.
>
> Signed-off-by: Mark Rutland
> Cc: Christoffer Dall
> Cc:
est, as if the feature were really missing.
>
> Signed-off-by: Mark Rutland
> Cc: Christoffer Dall
> Cc: Marc Zyngier
> Cc: kvmarm@lists.cs.columbia.edu
> ---
> arch/arm64/kvm/handle_exit.c | 18 ++
> arch/arm64/kvm/sys_regs.c| 9 +
> 2 files chang
>
> We now use mov_q to generate the HCR_EL2 value, as we use when
> configuring other registers in head.S.
>
> Signed-off-by: Mark Rutland
> Cc: Catalin Marinas
> Cc: Christoffer Dall
> Cc: Marc Zyngier
> Cc: Will Deacon
> Cc: kvmarm@lists.cs.columbia.edu
>
.
> + *
> + * Just in case this mismatch is seen, detect it, warn and give
> + * up. Supporting this forbidden configuration in Hyp would be
> + * pointless.
> + */
> + if (system_supports_sve() && !has_v
> preempt_disable();
>
> - /* Flush FP/SIMD state that can't survive guest entry/exit */
> - kvm_fpsimd_flush_cpu_state();
> -
> kvm_pmu_flush_hwstate(vcpu);
>
> local_irq_disable();
> --
> 2.1.4
>
> ___
> kvmarm mailing list
> kvmarm@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Acked-by: Christoffer Dall
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
On Thu, Apr 26, 2018 at 03:11:49PM +0100, Dave Martin wrote:
> On Thu, Apr 26, 2018 at 01:21:22PM +0200, Christoffer Dall wrote:
> > On Fri, Apr 20, 2018 at 05:46:37PM +0100, Dave Martin wrote:
> > > This patch refactors KVM to align the host and guest FPSIMD
> > > s
rq()
> KVM: arm/arm64: vgic: fix possible spectre-v1 in vgic_mmio_read_apr()
For the KVM-related parts:
Acked-by: Christoffer Dall
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
ver, it is still needed for
> preserving other things such as the host's system registers. To
> avoid ABI churn, the redundant storage space in host_cpu_context is
> not removed for now.
>
> arch/arm is not addressed by this patch and continues to use its
> current save/res
On Thu, Apr 26, 2018 at 11:56:10AM +0200, Auger Eric wrote:
>
>
> On 04/24/2018 11:08 PM, Christoffer Dall wrote:
> > On Fri, Apr 13, 2018 at 10:20:55AM +0200, Eric Auger wrote:
> >> On vcpu first run, we eventually know the actual number of vcpus.
> >> This is
On Thu, Apr 26, 2018 at 11:25:06AM +0200, Auger Eric wrote:
> Hi Christoffer,
>
> On 04/24/2018 11:07 PM, Christoffer Dall wrote:
> > On Fri, Apr 13, 2018 at 10:20:54AM +0200, Eric Auger wrote:
> >> As we are going to register several redist regions,
> >> vgic_re
On Thu, Apr 26, 2018 at 10:29:35AM +0200, Auger Eric wrote:
> Hi Christoffer,
> On 04/24/2018 11:07 PM, Christoffer Dall wrote:
> > On Fri, Apr 13, 2018 at 10:20:53AM +0200, Eric Auger wrote:
> >> We introduce a new helper to check there is no overlap between
> >
On Thu, Apr 26, 2018 at 09:32:49AM +0200, Auger Eric wrote:
> Hi Christoffer,
>
> On 04/24/2018 06:47 PM, Christoffer Dall wrote:
> > On Fri, Apr 13, 2018 at 10:20:52AM +0200, Eric Auger wrote:
> >> We introduce a new helper that creates and inserts a new redistributor
&g
On Tue, Apr 24, 2018 at 05:50:37PM +0100, Peter Maydell wrote:
> On 24 April 2018 at 17:46, Christoffer Dall wrote:
> > On Fri, Apr 13, 2018 at 10:20:48AM +0200, Eric Auger wrote:
> >> --- a/Documentation/virtual/kvm/devices/arm-vgic-v3.txt
> >> +++ b/Documentation/virt
_VGIC_V3_ADDR_TYPE_DIST 2
> +#define KVM_VGIC_V3_ADDR_TYPE_REDIST 3
> +#define KVM_VGIC_ITS_ADDR_TYPE 4
> +#define KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION 5
>
> #define KVM_VGIC_V3_DIST_SIZESZ_64K
> #define KVM_VGIC_V3_REDIST_SI
On Fri, Apr 13, 2018 at 10:20:55AM +0200, Eric Auger wrote:
> On vcpu first run, we eventually know the actual number of vcpus.
> This is a synchronization point to check all redistributors regions
> were assigned.
Isn't it the other way around? We want to check that all redistributors
(one for e
On Fri, Apr 13, 2018 at 10:20:54AM +0200, Eric Auger wrote:
> As we are going to register several redist regions,
> vgic_register_all_redist_iodevs() may be called several times. We need
> to register a redist_iodev for a given vcpu only once.
Wouldn't it be more natural to change that caller to
On Fri, Apr 13, 2018 at 10:20:53AM +0200, Eric Auger wrote:
> We introduce a new helper to check there is no overlap between
> dist region (if set) and registered rdist regions. This both
> handles the case of legacy single rdist region (implicitly sized
> with the number of online vcpus) and the n
free_slot(struct list_head *rdregs);
> +
> int vgic_its_resolve_lpi(struct kvm *kvm, struct vgic_its *its,
>u32 devid, u32 eventid, struct vgic_irq **irq);
> struct vgic_its *vgic_msi_to_its(struct kvm *kvm, struct kvm_msi *msi);
> --
> 2.5.5
>
Asides from the above:
Reviewed-by: Christoffer Dall
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
PER last bit.
>
> Signed-off-by: Eric Auger
Reviewed-by: Christoffer Dall
> ---
> include/kvm/arm_vgic.h | 14 +
> virt/kvm/arm/vgic/vgic-init.c | 16 --
> virt/kvm/arm/vgic/vgic-kvm-device.c | 13 ++
)
> +
> + if (addr == last_rdist_typer)
> value |= GICR_TYPER_LAST;
> if (vgic_has_its(vcpu->kvm))
> value |= GICR_TYPER_PLPIS;
> --
> 2.5.5
>
Reviewed-by: Christoffer Dall
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
-off-by: Eric Auger
> Reviewed-by: Marc Zyngier
Reviewed-by: Christoffer Dall
>
> ---
>
> v2 -> v3:
> - added Marc's R-b and Fixed commit
> ---
> virt/kvm/arm/vgic/vgic-init.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/virt/kvm/arm/vgic/vgi
On Fri, Apr 13, 2018 at 10:20:57AM +0200, Eric Auger wrote:
> Now all the internals are ready to handle multiple redistributor
> regions, let's allow the userspace to register them.
>
> Signed-off-by: Eric Auger
>
> ---
>
> v2 -> v3:
> - early exit if vgic_v3_rdist_region_from_index() fails
> -
On Fri, Apr 13, 2018 at 10:20:52AM +0200, Eric Auger wrote:
> We introduce a new helper that creates and inserts a new redistributor
> region into the rdist region list. This helper both handles the case
> where the redistributor region size is known at registration time
> and the legacy case where
On Fri, Apr 13, 2018 at 10:20:48AM +0200, Eric Auger wrote:
> We introduce a new KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION attribute in
> KVM_DEV_ARM_VGIC_GRP_ADDR group. It allows userspace to provide the
> base address and size of a redistributor region
>
> Compared to KVM_VGIC_V3_ADDR_TYPE_REDIST, th
e new IRQ to the list, but only
> after dropping the locks.
>
> Reported-by: Stefano Stabellini
> Signed-off-by: Andre Przywara
Reviewed-by: Christoffer Dall
> ---
> virt/kvm/arm/vgic/vgic.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/virt/kvm/arm
the feature.
>
> Let's turn these message into kvm_debug so that they can only
> be seen if CONFIG_DYNAMIC_DEBUG, and kept quiet otherwise.
>
> Signed-off-by: Marc Zyngier
Acked-by: Christoffer Dall
> ---
> arch/arm64/kvm/sys_regs.c | 6 ++
> 1 file changed,
Update my e-mail address to a working address.
Signed-off-by: Christoffer Dall
---
MAINTAINERS | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 0a1410d5a621..3e9c99d2620b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7738,7 +7738,7 @@ F
On Tue, Apr 10, 2018 at 04:37:12PM +0100, Marc Zyngier wrote:
> On 10/04/18 16:24, Mark Rutland wrote:
> > On Tue, Apr 10, 2018 at 05:05:40PM +0200, Christoffer Dall wrote:
> >> On Tue, Apr 10, 2018 at 11:51:19AM +0100, Mark Rutland wrote:
> >>> I think we also
On Tue, Apr 10, 2018 at 04:24:20PM +0100, Mark Rutland wrote:
> On Tue, Apr 10, 2018 at 05:05:40PM +0200, Christoffer Dall wrote:
> > On Tue, Apr 10, 2018 at 11:51:19AM +0100, Mark Rutland wrote:
> > > I think we also need to update kvm->arch.vttbr before updating
>
On Tue, Apr 10, 2018 at 11:32:50AM +0100, Dave Martin wrote:
> On Mon, Apr 09, 2018 at 11:22:43PM +0200, Christoffer Dall wrote:
> > Hi Dave,
> >
> > On Mon, Apr 09, 2018 at 11:53:02AM +0100, Dave Martin wrote:
> > > This patch refactors KVM to align the host and g
On Tue, Apr 10, 2018 at 11:51:19AM +0100, Mark Rutland wrote:
> On Mon, Apr 09, 2018 at 10:51:39PM +0200, Christoffer Dall wrote:
> > On Mon, Apr 09, 2018 at 06:07:06PM +0100, Marc Zyngier wrote:
> > > Before entering the guest, we check whether our VMID is still
> &g
Hi Eric,
On Tue, Mar 27, 2018 at 04:04:06PM +0200, Eric Auger wrote:
> We introduce a new KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION attribute in
> KVM_DEV_ARM_VGIC_GRP_ADDR group. It allows userspace to provide the
> base address and size of a redistributor region
>
> Compared to KVM_VGIC_V3_ADDR_TYPE_
Hi Dave,
On Mon, Apr 09, 2018 at 11:53:02AM +0100, Dave Martin wrote:
> This patch refactors KVM to align the host and guest FPSIMD
> save/restore logic with each other for arm64. This reduces the
> number of redundant save/restore operations that must occur, and
> reduces the common-case IRQ bla
On Mon, Apr 09, 2018 at 06:07:06PM +0100, Marc Zyngier wrote:
> Before entering the guest, we check whether our VMID is still
> part of the current generation. In order to avoid taking a lock,
> we start with checking that the generation is still current, and
> only if not current do we take the lo
On Mon, Apr 09, 2018 at 03:57:09PM +0100, Mark Rutland wrote:
> On Tue, Feb 06, 2018 at 01:39:15PM +0100, Christoffer Dall wrote:
> > On Mon, Nov 27, 2017 at 04:38:03PM +, Mark Rutland wrote:
> > > diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> &
On Mon, Apr 09, 2018 at 01:47:50PM +0100, Marc Zyngier wrote:
> +Drew, who's look at the whole save/restore thing extensively
>
> On 09/04/18 13:30, Christoffer Dall wrote:
> > On Thu, Mar 15, 2018 at 07:26:48PM +, Marc Zyngier wrote:
> >> On 15/03/18 19:13, Pet
Hi Mark,
[Sorry for late reply]
On Fri, Mar 09, 2018 at 02:28:38PM +, Mark Rutland wrote:
> On Tue, Feb 06, 2018 at 01:38:47PM +0100, Christoffer Dall wrote:
> > On Mon, Nov 27, 2017 at 04:38:04PM +, Mark Rutland wrote:
> > > When pointer authentication is supported, a
a
> strict superset of 0.2 (apart from the version number...).
>
> (2) A guest migrating from a "new" host to an "old" host will silently
> loose its Spectre v2 mitigation. That's quite a big deal.
>
> (3, not related to migration) A guest having a hardcode
On Mon, Apr 09, 2018 at 11:00:40AM +0100, Marc Zyngier wrote:
> On 09/04/18 10:44, Christoffer Dall wrote:
> > On Fri, Apr 06, 2018 at 04:51:53PM +0100, Dave Martin wrote:
> >> On Fri, Apr 06, 2018 at 04:25:57PM +0100, Marc Zyngier wrote:
> >>> Hi Dave,
> >>
On Fri, Apr 06, 2018 at 04:01:04PM +0100, Dave Martin wrote:
> This patch refactors KVM to align the host and guest FPSIMD
> save/restore logic with each other for arm64. This reduces the
> number of redundant save/restore operations that must occur, and
> reduces the common-case IRQ blackout time
On Fri, Apr 06, 2018 at 04:51:53PM +0100, Dave Martin wrote:
> On Fri, Apr 06, 2018 at 04:25:57PM +0100, Marc Zyngier wrote:
> > Hi Dave,
> >
> > On 06/04/18 16:01, Dave Martin wrote:
> > > To make the lazy FPSIMD context switch trap code easier to hack on,
> > > this patch converts it to C.
> > >
On Tue, Mar 06, 2018 at 09:21:06AM +, Andre Przywara wrote:
> Our irq_is_pending() helper function accesses multiple members of the
> vgic_irq struct, so we need to hold the lock when calling it.
For the record I don't think this is necessarily a completely valid
conclusion. The fact that you
reading stuff from the sysregs.
>
> The fix is pretty easy: turn dsb(st) into dsb(sy), and slap an isb()
> just after.
>
> Cc: sta...@vger.kernel.org
> Fixes: f68d2b1b73cc ("arm64: KVM: Implement vgic-v3 save/restore")
> Reviewed-by: Andre Przywara
> Signed-off
ed-off-by: Marc Zyngier
The fact that we have to do this is really annoying, but I see not other
way around it. It will get slightly better if we move to insertion sort
based on priorities when injecting interrupts as discussed with Andre,
though.
Acked-by: Christoffer Dall
> ---
> incl
On Sat, Mar 10, 2018 at 12:20 PM, Marc Zyngier wrote:
> On Fri, 09 Mar 2018 21:36:12 +,
> Christoffer Dall wrote:
>>
>> On Thu, Mar 08, 2018 at 05:28:44PM +, Marc Zyngier wrote:
>> > I'd be more confident if we did forbid P+A for such interrupts
>>
On Sat, Mar 10, 2018 at 1:57 PM, Marc Zyngier wrote:
> Hi Christoffer,
>
> On Fri, 09 Mar 2018 21:39:31 +,
> Christoffer Dall wrote:
>>
>> On Thu, Mar 08, 2018 at 06:39:20PM +, Marc Zyngier wrote:
>> > Thinking of it a bit more: MI on EOI doesn't off
On Thu, Mar 08, 2018 at 06:39:20PM +, Marc Zyngier wrote:
> On Thu, 08 Mar 2018 17:04:38 +,
> Marc Zyngier wrote:
> >
> > On Thu, 08 Mar 2018 16:02:42 +0000,
> > Christoffer Dall wrote:
> > >
> > > On Thu, Mar 08, 2018 at 10:19:49AM +, Mar
On Thu, Mar 08, 2018 at 05:28:44PM +, Marc Zyngier wrote:
> On Thu, 08 Mar 2018 16:19:00 +,
> Christoffer Dall wrote:
> >
> > On Thu, Mar 08, 2018 at 11:54:27AM +, Marc Zyngier wrote:
> > > On 08/03/18 09:49, Marc Zyngier wrote:
[...]
> > > Th
On Thu, Mar 08, 2018 at 11:54:27AM +, Marc Zyngier wrote:
> On 08/03/18 09:49, Marc Zyngier wrote:
> > [updated Christoffer's email address]
> >
> > Hi Shunyong,
> >
> > On 08/03/18 07:01, Shunyong Yang wrote:
> >> When resampling irqfds is enabled, level interrupt should be
> >> de-asserted
On Thu, Mar 08, 2018 at 09:49:43AM +, Marc Zyngier wrote:
> [updated Christoffer's email address]
>
> Hi Shunyong,
>
> On 08/03/18 07:01, Shunyong Yang wrote:
> > When resampling irqfds is enabled, level interrupt should be
> > de-asserted when resampling happens. On page 4-47 of GIC v3
> > s
On Thu, Mar 08, 2018 at 10:19:49AM +, Marc Zyngier wrote:
> On 07/03/18 23:34, Christoffer Dall wrote:
> > On Wed, Mar 7, 2018 at 12:40 PM, Marc Zyngier wrote:
> >> The vgic code is trying to be clever when injecting GICv2 SGIs,
> >> and will happily populate
On Wed, Mar 7, 2018 at 12:40 PM, Marc Zyngier wrote:
> The vgic code is trying to be clever when injecting GICv2 SGIs,
> and will happily populate LRs with the same interrupt number if
> they come from multiple vcpus (after all, they are distinct
> interrupt sources).
>
> Unfortunately, this is ag
the timer uses mapped interrupts, so we call this
function from the timer reset logic.
Signed-off-by: Christoffer Dall
---
This depends on "KVM: arm/arm64: Avoid vcpu_load for other vcpu ioctls
than KVM_RUN" from the VHE optimization series so that the reset doesn't
get calle
On Tue, Feb 27, 2018 at 05:34:28PM +0530, btha...@codeaurora.org wrote:
> Hi Christoffer,
>
> Thanks for your reply.
>
> On 2018-02-27 16:17, Christoffer Dall wrote:
> >Hi Bhupinder,
> >
> >On Tue, Feb 27, 2018 at 03:01:17PM +0530, btha...@codeaurora.org wrote:
From: Christoffer Dall
We can finally get completely rid of any calls to the VGICv3
save/restore functions when the AP lists are empty on VHE systems. This
requires carefully factoring out trap configuration from saving and
restoring state, and carefully choosing what to do on the VHE and
non
From: Christoffer Dall
The APRs can only have bits set when the guest acknowledges an interrupt
in the LR and can only have a bit cleared when the guest EOIs an
interrupt in the LR. Therefore, if we have no LRs with any
pending/active interrupts, the APR cannot change value and there is no
need
From: Christoffer Dall
We can program the GICv2 hypervisor control interface logic directly
from the core vgic code and can instead do the save/restore directly
from the flush/sync functions, which can lead to a number of future
optimizations.
Signed-off-by: Christoffer Dall
---
Notes
From: Christoffer Dall
The vgic-v2-sr.c file now only contains the logic to replay unaligned
accesses to the virtual CPU interface on 16K and 64K page systems, which
is only relevant on 64-bit platforms. Therefore move this file to the
arm64 KVM tree, remove the compile directive from the 32
From: Christoffer Dall
Just like we can program the GICv2 hypervisor control interface directly
from the core vgic code, we can do the same for the GICv3 hypervisor
control interface on VHE systems.
We do this by simply calling the save/restore functions when we have VHE
and we can then get rid
From: Christoffer Dall
We do not have to change the c15 trap setting on each switch to/from the
guest on VHE systems, because this setting only affects guest EL1/EL0
(and therefore not the VHE host).
The PMU and debug trap configuration can also be done on vcpu load/put
instead, because they
From: Christoffer Dall
There is really no need to store the vgic_elrsr on the VGIC data
structures as the only need we have for the elrsr is to figure out if an
LR is inactive when we save the VGIC state upon returning from the
guest. We can might as well store this in a temporary local
From: Christoffer Dall
To make the code more readable and to avoid the overhead of a function
call, let's get rid of a pair of the alternative function selectors and
explicitly call the VHE and non-VHE functions using the has_vhe() static
key based selector instead, telling the compiler t
From: Christoffer Dall
As we are about to be more lazy with some of the trap configuration
register read/writes for VHE systems, move the logic that is currently
shared between VHE and non-VHE into a separate function which can be
called from either the world-switch path or from vcpu_load
From: Christoffer Dall
There is no longer a need for an alternative to choose the right
function to tell us whether or not FPSIMD was enabled for the VM,
because we can simply can the appropriate functions directly from within
the _vhe and _nvhe run functions.
Reviewed-by: Marc Zyngier
From: Christoffer Dall
When running a 32-bit VM (EL1 in AArch32), the AArch32 system registers
can be deferred to vcpu load/put on VHE systems because neither
the host kernel nor host userspace uses these registers.
Note that we can't save DBGVCR32_EL2 conditionally based on the state o
From: Christoffer Dall
Some system registers do not affect the host kernel's execution and can
therefore be loaded when we are about to run a VCPU and we don't have to
restore the host state to the hardware before the time when we are
actually about to return to userspace or schedu
From: Christoffer Dall
32-bit registers are not used by a 64-bit host kernel and can be
deferred, but we need to rework the accesses to these register to access
the latest values depending on whether or not guest system registers are
loaded on the CPU or only reside in memory.
Reviewed-by: Marc
From: Christoffer Dall
Currently we access the system registers array via the vcpu_sys_reg()
macro. However, we are about to change the behavior to some times
modify the register file directly, so let's change this to two
primitives:
* Accessor macros vcpu_write_sys_reg(
From: Christoffer Dall
SPSR_EL1 is not used by a VHE host kernel and can be deferred, but we
need to rework the accesses to this register to access the latest value
depending on whether or not guest system registers are loaded on the CPU
or only reside in memory.
The handling of accessing the
From: Christoffer Dall
ELR_EL1 is not used by a VHE host kernel and can be deferred, but we
need to rework the accesses to this register to access the latest value
depending on whether or not guest system registers are loaded on the CPU
or only reside in memory.
Reviewed-by: Marc Zyngier
From: Christoffer Dall
We are about to defer saving and restoring some groups of system
registers to vcpu_put and vcpu_load on supported systems. This means
that we need some infrastructure to access system registes which
supports either accessing the memory backing of the register or directly
From: Christoffer Dall
We currently handle 32-bit accesses to trapped VM system registers using
the 32-bit index into the coproc array on the vcpu structure, which is a
union of the coproc array and the sysreg array.
Since all the 32-bit coproc indices are created to correspond to the
From: Christoffer Dall
On non-VHE systems we need to save the ELR_EL2 and SPSR_EL2 so that we can
return to the host in EL1 in the same state and location where we issued a
hypercall to EL2, but on VHE ELR_EL2 and SPSR_EL2 are not useful because we
never enter a guest as a result of an exception
From: Christoffer Dall
There is no need to have multiple identical functions with different
names for saving host and guest state. When saving and restoring state
for the host and guest, the state is the same for both contexts, and
that's why we have the kvm_cpu_context structure. Delet
From: Christoffer Dall
The comment only applied to SPE on non-VHE systems, so we simply remove
it.
Suggested-by: Andrew Jones
Acked-by: Marc Zyngier
Reviewed-by: Andrew Jones
Signed-off-by: Christoffer Dall
---
arch/arm64/kvm/hyp/switch.c | 4
1 file changed, 4 deletions(-)
diff
From: Christoffer Dall
As we are about to handle system registers quite differently between VHE
and non-VHE systems. In preparation for that, we need to split some of
the handling functions between VHE and non-VHE functionality.
For now, we simply copy the non-VHE functions, but we do change
From: Christoffer Dall
As we are about to move calls around in the sysreg save/restore logic,
let's first rewrite the alternative function callers, because it is
going to make the next patches much easier to read.
Acked-by: Marc Zyngier
Reviewed-by: Andrew Jones
Signed-off-by: Christ
From: Christoffer Dall
There's a semantic difference between the EL1 registers that control
operation of a kernel running in EL1 and EL1 registers that only control
userspace execution in EL0. Since we can defer saving/restoring the
latter, move them into their own function.
The ARMv8 ARM
From: Christoffer Dall
The VHE switch function calls __timer_enable_traps and
__timer_disable_traps which don't do anything on VHE systems.
Therefore, simply remove these calls from the VHE switch function and
make the functions non-conditional as they are now only called from the
non-VHE s
From: Christoffer Dall
There is no need to reset the VTTBR to zero when exiting the guest on
VHE systems. VHE systems don't use stage 2 translations for the EL2&0
translation regime used by the host.
Reviewed-by: Andrew Jones
Acked-by: Marc Zyngier
Signed-off-by: Christoffer Dall
-
From: Christoffer Dall
So far this is mostly (see below) a copy of the legacy non-VHE switch
function, but we will start reworking these functions in separate
directions to work on VHE and non-VHE in the most optimal way in later
patches.
The only difference after this patch between the VHE and
From: Christoffer Dall
VHE kernels run completely in EL2 and therefore don't have a notion of
kernel and hyp addresses, they are all just kernel addresses. Therefore
don't call kern_hyp_va() in the VHE switch function.
Reviewed-by: Andrew Jones
Reviewed-by: Marc Zyngier
Sig
From: Christoffer Dall
Instead of having multiple calls from the world switch path to the debug
logic, each figuring out if the dirty bit is set and if we should
save/restore the debug registers, let's just provide two hooks to the
debug save/restore functionality, one for switching to the
From: Christoffer Dall
The current world-switch function has functionality to detect a number
of cases where we need to fixup some part of the exit condition and
possibly run the guest again, before having restored the host state.
This includes populating missing fault info, emulating GICv2 CPU
From: Christoffer Dall
The debug save/restore functions can be improved by using the has_vhe()
static key instead of the instruction alternative. Using the static key
uses the same paradigm as we're going to use elsewhere, it makes the
code more readable, and it generates slightly better
From: Christoffer Dall
There is no need to figure out inside the world-switch if we should
save/restore the debug registers or not, we might as well do that in the
higher level debug setup code, making it easier to optimize down the
line.
Reviewed-by: Julien Thierry
Reviewed-by: Marc Zyngier
e the HCR_RW bit set when returning to EL1 on non-VHE systems.
Reviewed-by: Marc Zyngier
Signed-off-by: Shih-Wei Li
Signed-off-by: Christoffer Dall
---
Notes:
Changes since v3:
- Slightly reworded the commit message
arch/arm64/include/asm/kvm_arm.h | 4 ++--
arch/arm64/kvm/hyp/swi
From: Christoffer Dall
We have numerous checks around that checks if the HCR_EL2 has the RW bit
set to figure out if we're running an AArch64 or AArch32 VM. In some
cases, directly checking the RW bit (given its unintuitive name), is a
bit confusing, and that's not going to improve
From: Christoffer Dall
As we are about to move a bunch of save/restore logic for VHE kernels to
the load and put functions, we need some infrastructure to do this.
Reviewed-by: Andrew Jones
Acked-by: Marc Zyngier
Signed-off-by: Christoffer Dall
---
Notes:
Changes since v1
From: Christoffer Dall
We currently have a separate read-modify-write of the HCR_EL2 on entry
to the guest for the sole purpose of setting the VF and VI bits, if set.
Since this is most rarely the case (only when using userspace IRQ chip
and interrupts are in flight), let's get rid of
From: Christoffer Dall
VHE actually doesn't rely on clearing the VTTBR when returning to the
host kernel, and that is the current key mechanism of hyp_panic to
figure out how to attempt to return to a state good enough to print a
panic statement.
Therefore, we split the hyp_panic function
From: Christoffer Dall
Moving the call to vcpu_load() in kvm_arch_vcpu_ioctl_run() to after
we've called kvm_vcpu_first_run_init() simplifies some of the vgic and
there is also no need to do vcpu_load() for things such as handling the
immediate_exit flag.
Reviewed-by: Julien Grall
Review
From: Christoffer Dall
We already have the percpu area for the host cpu state, which points to
the VCPU, so there's no need to store the VCPU pointer on the stack on
every context switch. We can be a little more clever and just use
tpidr_el2 for the percpu offset and load the VCPU pointer
From: Christoffer Dall
Calling vcpu_load() registers preempt notifiers for this vcpu and calls
kvm_arch_vcpu_load(). The latter will soon be doing a lot of heavy
lifting on arm/arm64 and will try to do things such as enabling the
virtual timer and setting us up to handle interrupts from the
Addressed review comments from v2 (detailed changelogs are in the
individual patches).
Thanks,
-Christoffer
Christoffer Dall (39):
KVM: arm/arm64: Avoid vcpu_load for other vcpu ioctls than KVM_RUN
KVM: arm/arm64: Move vcpu_load call after kvm_vcpu_first_run_init
KVM: arm64: Avoid storing
Hi Bhupinder,
On Tue, Feb 27, 2018 at 03:01:17PM +0530, btha...@codeaurora.org wrote:
> I hope it is the right forum to post my query.
>
>
>
> I am currently looking at the possibility of adding a new VCPU to a running
> guest VM in KVM/ARM. I see that currently, it is not allowed to add a new
On Fri, Feb 23, 2018 at 02:30:54PM +, Julien Grall wrote:
> Hi Christoffer,
>
> On 15/02/18 21:03, Christoffer Dall wrote:
> >@@ -85,37 +123,14 @@ static void __hyp_text __activate_traps(struct kvm_vcpu
> >*vcpu)
> > {
> > u64 hcr = vcpu->arch.hcr_el2
401 - 500 of 3909 matches
Mail list logo
