On 2020/2/8 0:34, Marc Zyngier wrote:
Accessing a per-cpu variable only makes sense when preemption is
disabled (and the kernel does check this when the right debug options
are switched on).
For kvm_get_running_vcpu(), it is fine to return the value after
re-enabling preemption, as the preempt n
On Mon, Feb 10, 2020 at 04:37:53PM +, Suzuki Kuruppassery Poulose wrote:
> On 10/02/2020 12:27, Mark Rutland wrote:
> > When cpus_have_const_cap() was originally introduced it was intended to
> > be safe in hyp context, where it is not safe to access the cpu_hwcaps
> > array as cpus_have_cap()
On 10/02/2020 12:27, Mark Rutland wrote:
When cpus_have_const_cap() was originally introduced it was intended to
be safe in hyp context, where it is not safe to access the cpu_hwcaps
array as cpus_have_cap() did. For more details see commit:
a4023f682739439b ("arm64: Add hypervisor safe helpe
On Mon, Feb 10, 2020 at 04:25:23PM +, Russell King - ARM Linux admin wrote:
> On Mon, Feb 10, 2020 at 02:13:19PM +, Marc Zyngier wrote:
> > KVM/arm was merged just over 7 years ago, and has lived a very quiet
> > life so far. It mostly works if you're prepared to deal with its
> > limitatio
On Mon, Feb 10, 2020 at 02:13:19PM +, Marc Zyngier wrote:
> KVM/arm was merged just over 7 years ago, and has lived a very quiet
> life so far. It mostly works if you're prepared to deal with its
> limitations, it has been a good prototype for the arm64 version,
> but it suffers a few problems:
On Mon, Feb 10, 2020 at 4:32 PM Olof Johansson wrote:
> On Mon, Feb 10, 2020 at 3:13 PM Marc Zyngier wrote:
> >
> > KVM/arm was merged just over 7 years ago, and has lived a very quiet
> > life so far. It mostly works if you're prepared to deal with its
> > limitations, it has been a good prototy
On Mon, Feb 10, 2020 at 02:13:19PM +, Marc Zyngier wrote:
> KVM/arm was merged just over 7 years ago, and has lived a very quiet
> life so far. It mostly works if you're prepared to deal with its
> limitations, it has been a good prototype for the arm64 version,
> but it suffers a few problems:
On Mon, Feb 10, 2020 at 3:13 PM Marc Zyngier wrote:
>
> KVM/arm was merged just over 7 years ago, and has lived a very quiet
> life so far. It mostly works if you're prepared to deal with its
> limitations, it has been a good prototype for the arm64 version,
> but it suffers a few problems:
>
> -
That's it. Remove all references to KVM itself, and document
that although it is no more, the ABI between SVC and HYP still
exists.
Signed-off-by: Marc Zyngier
---
Documentation/virt/kvm/arm/hyp-abi.txt |5 +
arch/arm/include/asm/kvm_arm.h | 239
arch/arm/include/asm/kvm_asm.h
We used to use a set of macros to provide support of vgic-v3 to 32bit
without duplicating everything. We don't need it anymore, so drop it.
Signed-off-by: Marc Zyngier
---
arch/arm/include/asm/arch_gicv3.h | 114 --
1 file changed, 114 deletions(-)
diff --git a/arch/
Only one platform is building KVM by default. How crazy! Remove
it whilst nobody is watching.
Signed-off-by: Marc Zyngier
---
arch/arm/configs/axm55xx_defconfig | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/configs/axm55xx_defconfig
b/arch/arm/configs/axm55xx_defconfig
index f53
KVM/arm was merged just over 7 years ago, and has lived a very quiet
life so far. It mostly works if you're prepared to deal with its
limitations, it has been a good prototype for the arm64 version,
but it suffers a few problems:
- It is incomplete (no debug support, no PMU)
- It hasn't followed a
As we're about to drop KVM/arm on the floor, carefully unplug
it from the build system.
Signed-off-by: Marc Zyngier
---
arch/arm/Kconfig | 2 --
arch/arm/Makefile| 1 -
arch/arm/mach-exynos/Kconfig | 2 +-
3 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch
Remove all traces of Stage-2 and HYP page table support.
Signed-off-by: Marc Zyngier
---
arch/arm/include/asm/pgtable-3level.h | 20
arch/arm/include/asm/pgtable.h| 9 -
arch/arm/include/asm/sections.h | 6 +-
arch/arm/include/asm/virt.h
Across arm64 we use cpus_have_const_cap() to check for a capability
without a runtime check. Prior to capabilities being finalized
cpus_have_const_cap() falls back to a runtime check of the cpu_hwcaps
array. In some cases we know that code is never invoked prior to the
capabilities being finalized,
The KVM hyp code is only run after system capabilities have been
finalized, and thus all const cap checks have been patched. This is
noted in in __cpu_init_hyp_mode(), where we BUG() if called too early:
| /*
| * Call initialization code, and switch to the full blown HYP code.
| * If the cpucaps
When cpus_have_const_cap() was originally introduced it was intended to
be safe in hyp context, where it is not safe to access the cpu_hwcaps
array as cpus_have_cap() did. For more details see commit:
a4023f682739439b ("arm64: Add hypervisor safe helper for checking constant
capabilities")
We
With VHE, running a vCPU always requires the sequence:
1. kvm_arm_vhe_guest_enter();
2. kvm_vcpu_run_vhe();
3. kvm_arm_vhe_guest_exit()
... and as we invoke this from the shared arm/arm64 KVM code, 32-bit arm
has to provide stubs for all three functions.
To simplify the common code, and make it
Currently, there is no mechanism to keep time sync between guest and host
in arm/arm64 virtualization environment. Time in guest will drift compared
with host after boot up as they may both use third party time sources
to correct their time respectively. The time deviation will be in order
of milli
sometimes we may need tell getcrosstimestamp call back how to perform
itself. Extending input arguments for getcrosstimestamp API to offer more
exquisite control for the operation.
Signed-off-by: Jianyong Wu
---
drivers/clocksource/arm_arch_timer.c| 2 +-
drivers/net/ethernet/intel/e1000e/pt
ptp_kvm modules will get this service through smccc call.
The service offers real time and counter cycle of host for guest.
Also let caller determine which cycle of virtual counter or physical counter
to return.
Signed-off-by: Jianyong Wu
---
include/linux/arm-smccc.h | 21 +++
v
Let userspace check if there is kvm ptp service in host.
Before VMs migrate to another host, VMM may check if this
cap is available to determine the next behavior.
Signed-off-by: Jianyong Wu
Suggested-by: Marc Zyngier
---
include/uapi/linux/kvm.h | 1 +
virt/kvm/arm/arm.c | 1 +
2 files c
In general, vm inside will use virtual counter compered with host use
phyical counter. But in some special scenarios, like nested virtualization,
phyical counter maybe used by vm. A interface added in ptp_kvm driver to
offer a mechanism to let user choose which counter should be return from
host.
T
kvm ptp targets to provide high precision time sync between guest
and host in virtualization environment. Here, we enable kvm ptp
for arm64.
change log:
from v10 to v9
(1) change code base to v5.5.
(2) enable ptp_kvm both for arm32 and arm64.
(3) let user choose which of vi
Export arm_smccc_1_1_get_conduit then modules can use smccc helper which
adopts it.
Signed-off-by: Jianyong Wu
---
drivers/firmware/psci/psci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
index b3b6c15e7b36..e0738d6f3d16 100644
Add clocksource id for arm arch counter to let it be identified easily and
elegantly in ptp_kvm implementation for arm.
Signed-off-by: Jianyong Wu
---
drivers/clocksource/arm_arch_timer.c | 2 ++
include/linux/clocksource_ids.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/c
From: Thomas Gleixner
System time snapshots are not conveying information about the current
clocksource which was used, but callers like the PTP KVM guest
implementation have the requirement to evaluate the clocksource type to
select the appropriate mechanism.
Introduce a clocksource id field in
Currently, ptp_kvm modules implementation is only for x86 which includs
large part of arch-specific code. This patch move all of those code
into new arch related file in the same directory.
Signed-off-by: Jianyong Wu
---
drivers/ptp/Makefile| 1 +
drivers/ptp/ptp_kvm.h
28 matches
Mail list logo
