* [RFC PATCH 1/5] arm: Unplug KVM from the build system
2020-02-10 14:13 ` [RFC PATCH 0/5] Removing support for 32bit KVM/arm host Marc Zyngier
@ 2020-02-10 14:13 ` Marc Zyngier
2020-02-10 14:13 ` [RFC PATCH 2/5] arm: Remove KVM from config files Marc Zyngier
` (15 subsequent siblings)
16 siblings, 0 replies; 30+ messages in thread
From: Marc Zyngier @ 2020-02-10 14:13 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, kvm
Cc: Anders Berg, Russell King, Arnd Bergmann, Paolo Bonzini, Will Deacon
As we're about to drop KVM/arm on the floor, carefully unplug
it from the build system.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
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/arm/Kconfig b/arch/arm/Kconfig
index 97864aabc2a6..a07bec7f4d8d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2091,5 +2091,3 @@ source "drivers/firmware/Kconfig"
if CRYPTO
source "arch/arm/crypto/Kconfig"
endif
-
-source "arch/arm/kvm/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index db857d07114f..b4ce96f55ddd 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -278,7 +278,6 @@ core-$(CONFIG_FPE_NWFPE) += arch/arm/nwfpe/
core-$(CONFIG_FPE_FASTFPE) += $(patsubst $(srctree)/%,%,$(wildcard $(srctree)/arch/arm/fastfpe/))
core-$(CONFIG_VFP) += arch/arm/vfp/
core-$(CONFIG_XEN) += arch/arm/xen/
-core-$(CONFIG_KVM_ARM_HOST) += arch/arm/kvm/
core-$(CONFIG_VDSO) += arch/arm/vdso/
# If we have a machine-specific directory, then include it in the build.
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index cbbe03e96de8..76838255b5fa 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -21,7 +21,7 @@ menuconfig ARCH_EXYNOS
select EXYNOS_SROM
select EXYNOS_PM_DOMAINS if PM_GENERIC_DOMAINS
select GPIOLIB
- select HAVE_ARM_ARCH_TIMER if ARCH_EXYNOS5 && VIRTUALIZATION
+ select HAVE_ARM_ARCH_TIMER if ARCH_EXYNOS5
select HAVE_ARM_SCU if SMP
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG
--
2.20.1
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 30+ messages in thread* [RFC PATCH 2/5] arm: Remove KVM from config files
2020-02-10 14:13 ` [RFC PATCH 0/5] Removing support for 32bit KVM/arm host Marc Zyngier
2020-02-10 14:13 ` [RFC PATCH 1/5] arm: Unplug KVM from the build system Marc Zyngier
@ 2020-02-10 14:13 ` Marc Zyngier
2020-02-10 14:13 ` [RFC PATCH 3/5] arm: Remove 32bit KVM host support Marc Zyngier
` (14 subsequent siblings)
16 siblings, 0 replies; 30+ messages in thread
From: Marc Zyngier @ 2020-02-10 14:13 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, kvm
Cc: Anders Berg, Russell King, Arnd Bergmann, Paolo Bonzini, Will Deacon
Only one platform is building KVM by default. How crazy! Remove
it whilst nobody is watching.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
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 f53634af014b..ce10bc2af320 100644
--- a/arch/arm/configs/axm55xx_defconfig
+++ b/arch/arm/configs/axm55xx_defconfig
@@ -237,5 +237,3 @@ CONFIG_CRYPTO_GCM=y
CONFIG_CRYPTO_XCBC=y
CONFIG_CRYPTO_SHA256=y
# CONFIG_CRYPTO_ANSI_CPRNG is not set
-CONFIG_VIRTUALIZATION=y
-CONFIG_KVM=y
--
2.20.1
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 30+ messages in thread* [RFC PATCH 3/5] arm: Remove 32bit KVM host support
2020-02-10 14:13 ` [RFC PATCH 0/5] Removing support for 32bit KVM/arm host Marc Zyngier
2020-02-10 14:13 ` [RFC PATCH 1/5] arm: Unplug KVM from the build system Marc Zyngier
2020-02-10 14:13 ` [RFC PATCH 2/5] arm: Remove KVM from config files Marc Zyngier
@ 2020-02-10 14:13 ` Marc Zyngier
2020-02-10 14:13 ` [RFC PATCH 4/5] arm: Remove HYP/Stage-2 page-table support Marc Zyngier
` (13 subsequent siblings)
16 siblings, 0 replies; 30+ messages in thread
From: Marc Zyngier @ 2020-02-10 14:13 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, kvm
Cc: Anders Berg, Russell King, Arnd Bergmann, Paolo Bonzini, Will Deacon
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 <maz@kernel.org>
---
Documentation/virt/kvm/arm/hyp-abi.txt | 5 +
arch/arm/include/asm/kvm_arm.h | 239 ----
arch/arm/include/asm/kvm_asm.h | 77 --
arch/arm/include/asm/kvm_coproc.h | 36 -
arch/arm/include/asm/kvm_emulate.h | 372 ------
arch/arm/include/asm/kvm_host.h | 459 --------
arch/arm/include/asm/kvm_hyp.h | 127 ---
arch/arm/include/asm/kvm_mmu.h | 435 -------
arch/arm/include/asm/kvm_ras.h | 14 -
arch/arm/include/asm/stage2_pgtable.h | 75 --
arch/arm/include/asm/virt.h | 5 -
arch/arm/include/uapi/asm/kvm.h | 314 -----
arch/arm/kernel/asm-offsets.c | 11 -
arch/arm/kvm/Kconfig | 59 -
arch/arm/kvm/Makefile | 43 -
arch/arm/kvm/coproc.c | 1455 ------------------------
arch/arm/kvm/coproc.h | 130 ---
arch/arm/kvm/coproc_a15.c | 39 -
arch/arm/kvm/coproc_a7.c | 42 -
arch/arm/kvm/emulate.c | 166 ---
arch/arm/kvm/guest.c | 387 -------
arch/arm/kvm/handle_exit.c | 175 ---
arch/arm/kvm/hyp/Makefile | 34 -
arch/arm/kvm/hyp/banked-sr.c | 70 --
arch/arm/kvm/hyp/cp15-sr.c | 72 --
arch/arm/kvm/hyp/entry.S | 121 --
arch/arm/kvm/hyp/hyp-entry.S | 295 -----
arch/arm/kvm/hyp/s2-setup.c | 22 -
arch/arm/kvm/hyp/switch.c | 242 ----
arch/arm/kvm/hyp/tlb.c | 68 --
arch/arm/kvm/hyp/vfp.S | 57 -
arch/arm/kvm/init.S | 157 ---
arch/arm/kvm/interrupts.S | 36 -
arch/arm/kvm/irq.h | 16 -
arch/arm/kvm/reset.c | 86 --
arch/arm/kvm/trace.h | 86 --
arch/arm/kvm/vgic-v3-coproc.c | 27 -
37 files changed, 5 insertions(+), 6049 deletions(-)
delete mode 100644 arch/arm/include/asm/kvm_arm.h
delete mode 100644 arch/arm/include/asm/kvm_asm.h
delete mode 100644 arch/arm/include/asm/kvm_coproc.h
delete mode 100644 arch/arm/include/asm/kvm_emulate.h
delete mode 100644 arch/arm/include/asm/kvm_host.h
delete mode 100644 arch/arm/include/asm/kvm_hyp.h
delete mode 100644 arch/arm/include/asm/kvm_mmu.h
delete mode 100644 arch/arm/include/asm/kvm_ras.h
delete mode 100644 arch/arm/include/asm/stage2_pgtable.h
delete mode 100644 arch/arm/include/uapi/asm/kvm.h
delete mode 100644 arch/arm/kvm/Kconfig
delete mode 100644 arch/arm/kvm/Makefile
delete mode 100644 arch/arm/kvm/coproc.c
delete mode 100644 arch/arm/kvm/coproc.h
delete mode 100644 arch/arm/kvm/coproc_a15.c
delete mode 100644 arch/arm/kvm/coproc_a7.c
delete mode 100644 arch/arm/kvm/emulate.c
delete mode 100644 arch/arm/kvm/guest.c
delete mode 100644 arch/arm/kvm/handle_exit.c
delete mode 100644 arch/arm/kvm/hyp/Makefile
delete mode 100644 arch/arm/kvm/hyp/banked-sr.c
delete mode 100644 arch/arm/kvm/hyp/cp15-sr.c
delete mode 100644 arch/arm/kvm/hyp/entry.S
delete mode 100644 arch/arm/kvm/hyp/hyp-entry.S
delete mode 100644 arch/arm/kvm/hyp/s2-setup.c
delete mode 100644 arch/arm/kvm/hyp/switch.c
delete mode 100644 arch/arm/kvm/hyp/tlb.c
delete mode 100644 arch/arm/kvm/hyp/vfp.S
delete mode 100644 arch/arm/kvm/init.S
delete mode 100644 arch/arm/kvm/interrupts.S
delete mode 100644 arch/arm/kvm/irq.h
delete mode 100644 arch/arm/kvm/reset.c
delete mode 100644 arch/arm/kvm/trace.h
delete mode 100644 arch/arm/kvm/vgic-v3-coproc.c
diff --git a/Documentation/virt/kvm/arm/hyp-abi.txt b/Documentation/virt/kvm/arm/hyp-abi.txt
index a20a0bee268d..26a3be475000 100644
--- a/Documentation/virt/kvm/arm/hyp-abi.txt
+++ b/Documentation/virt/kvm/arm/hyp-abi.txt
@@ -7,6 +7,11 @@ hypervisor when running as a guest (under Xen, KVM or any other
hypervisor), or any hypervisor-specific interaction when the kernel is
used as a host.
+Note: KVM/arm has been removed from the kernel. The API described
+here is still valid though, as it allows the kernel to kexec when
+booted at HYP. It can also be used by a hypervisor other than KVM
+if necessary.
+
On arm and arm64 (without VHE), the kernel doesn't run in hypervisor
mode, but still needs to interact with it, allowing a built-in
hypervisor to be either installed or torn down.
diff --git a/arch/arm/include/asm/kvm_arm.h b/arch/arm/include/asm/kvm_arm.h
deleted file mode 100644
index 9c04bd810d07..000000000000
diff --git a/arch/arm/include/asm/kvm_asm.h b/arch/arm/include/asm/kvm_asm.h
deleted file mode 100644
index f615830f9f57..000000000000
diff --git a/arch/arm/include/asm/kvm_coproc.h b/arch/arm/include/asm/kvm_coproc.h
deleted file mode 100644
index a23826117dd6..000000000000
diff --git a/arch/arm/include/asm/kvm_emulate.h b/arch/arm/include/asm/kvm_emulate.h
deleted file mode 100644
index 3944305e81df..000000000000
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
deleted file mode 100644
index c3314b286a61..000000000000
diff --git a/arch/arm/include/asm/kvm_hyp.h b/arch/arm/include/asm/kvm_hyp.h
deleted file mode 100644
index 3c1b55ecc578..000000000000
diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
deleted file mode 100644
index 0d84d50bf9ba..000000000000
diff --git a/arch/arm/include/asm/kvm_ras.h b/arch/arm/include/asm/kvm_ras.h
deleted file mode 100644
index e9577292dfe4..000000000000
diff --git a/arch/arm/include/asm/stage2_pgtable.h b/arch/arm/include/asm/stage2_pgtable.h
deleted file mode 100644
index aaceec7855ec..000000000000
diff --git a/arch/arm/include/asm/virt.h b/arch/arm/include/asm/virt.h
index 17c26ccd126d..6cd4e33418e9 100644
--- a/arch/arm/include/asm/virt.h
+++ b/arch/arm/include/asm/virt.h
@@ -67,11 +67,6 @@ static inline bool is_kernel_in_hyp_mode(void)
return false;
}
-static inline bool has_vhe(void)
-{
- return false;
-}
-
/* The section containing the hypervisor idmap text */
extern char __hyp_idmap_text_start[];
extern char __hyp_idmap_text_end[];
diff --git a/arch/arm/include/uapi/asm/kvm.h b/arch/arm/include/uapi/asm/kvm.h
deleted file mode 100644
index 03cd7c19a683..000000000000
diff --git a/arch/arm/kernel/asm-offsets.c b/arch/arm/kernel/asm-offsets.c
index c773b829ee8e..c036a4a2f8e2 100644
--- a/arch/arm/kernel/asm-offsets.c
+++ b/arch/arm/kernel/asm-offsets.c
@@ -11,9 +11,6 @@
#include <linux/sched.h>
#include <linux/mm.h>
#include <linux/dma-mapping.h>
-#ifdef CONFIG_KVM_ARM_HOST
-#include <linux/kvm_host.h>
-#endif
#include <asm/cacheflush.h>
#include <asm/glue-df.h>
#include <asm/glue-pf.h>
@@ -167,14 +164,6 @@ int main(void)
DEFINE(CACHE_WRITEBACK_ORDER, __CACHE_WRITEBACK_ORDER);
DEFINE(CACHE_WRITEBACK_GRANULE, __CACHE_WRITEBACK_GRANULE);
BLANK();
-#ifdef CONFIG_KVM_ARM_HOST
- DEFINE(VCPU_GUEST_CTXT, offsetof(struct kvm_vcpu, arch.ctxt));
- DEFINE(VCPU_HOST_CTXT, offsetof(struct kvm_vcpu, arch.host_cpu_context));
- DEFINE(CPU_CTXT_VFP, offsetof(struct kvm_cpu_context, vfp));
- DEFINE(CPU_CTXT_GP_REGS, offsetof(struct kvm_cpu_context, gp_regs));
- DEFINE(GP_REGS_USR, offsetof(struct kvm_regs, usr_regs));
-#endif
- BLANK();
#ifdef CONFIG_VDSO
DEFINE(VDSO_DATA_SIZE, sizeof(union vdso_data_store));
#endif
diff --git a/arch/arm/kvm/Kconfig b/arch/arm/kvm/Kconfig
deleted file mode 100644
index f591026347a5..000000000000
diff --git a/arch/arm/kvm/Makefile b/arch/arm/kvm/Makefile
deleted file mode 100644
index e442d82821df..000000000000
diff --git a/arch/arm/kvm/coproc.c b/arch/arm/kvm/coproc.c
deleted file mode 100644
index 07745ee022a1..000000000000
diff --git a/arch/arm/kvm/coproc.h b/arch/arm/kvm/coproc.h
deleted file mode 100644
index 637065b13012..000000000000
diff --git a/arch/arm/kvm/coproc_a15.c b/arch/arm/kvm/coproc_a15.c
deleted file mode 100644
index 36bf15421ae8..000000000000
diff --git a/arch/arm/kvm/coproc_a7.c b/arch/arm/kvm/coproc_a7.c
deleted file mode 100644
index 40f643e1e05c..000000000000
diff --git a/arch/arm/kvm/emulate.c b/arch/arm/kvm/emulate.c
deleted file mode 100644
index 29bb852140c5..000000000000
diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
deleted file mode 100644
index 9f7ae0d8690f..000000000000
diff --git a/arch/arm/kvm/handle_exit.c b/arch/arm/kvm/handle_exit.c
deleted file mode 100644
index e58a89d2f13f..000000000000
diff --git a/arch/arm/kvm/hyp/Makefile b/arch/arm/kvm/hyp/Makefile
deleted file mode 100644
index ba88b1eca93c..000000000000
diff --git a/arch/arm/kvm/hyp/banked-sr.c b/arch/arm/kvm/hyp/banked-sr.c
deleted file mode 100644
index c4632ed9e819..000000000000
diff --git a/arch/arm/kvm/hyp/cp15-sr.c b/arch/arm/kvm/hyp/cp15-sr.c
deleted file mode 100644
index e6923306f698..000000000000
diff --git a/arch/arm/kvm/hyp/entry.S b/arch/arm/kvm/hyp/entry.S
deleted file mode 100644
index 4bd1f6a74180..000000000000
diff --git a/arch/arm/kvm/hyp/hyp-entry.S b/arch/arm/kvm/hyp/hyp-entry.S
deleted file mode 100644
index fe3d7811a908..000000000000
diff --git a/arch/arm/kvm/hyp/s2-setup.c b/arch/arm/kvm/hyp/s2-setup.c
deleted file mode 100644
index 5dfbea5adf65..000000000000
diff --git a/arch/arm/kvm/hyp/switch.c b/arch/arm/kvm/hyp/switch.c
deleted file mode 100644
index 1efeef3fd0ee..000000000000
diff --git a/arch/arm/kvm/hyp/tlb.c b/arch/arm/kvm/hyp/tlb.c
deleted file mode 100644
index 848f27bbad9d..000000000000
diff --git a/arch/arm/kvm/hyp/vfp.S b/arch/arm/kvm/hyp/vfp.S
deleted file mode 100644
index 675a52348d8d..000000000000
diff --git a/arch/arm/kvm/init.S b/arch/arm/kvm/init.S
deleted file mode 100644
index 33e34b6d24b2..000000000000
diff --git a/arch/arm/kvm/interrupts.S b/arch/arm/kvm/interrupts.S
deleted file mode 100644
index 064f4f118ca7..000000000000
diff --git a/arch/arm/kvm/irq.h b/arch/arm/kvm/irq.h
deleted file mode 100644
index 0d257de42c10..000000000000
diff --git a/arch/arm/kvm/reset.c b/arch/arm/kvm/reset.c
deleted file mode 100644
index eb4174f6ebbd..000000000000
diff --git a/arch/arm/kvm/trace.h b/arch/arm/kvm/trace.h
deleted file mode 100644
index 69a9d62a0ac6..000000000000
diff --git a/arch/arm/kvm/vgic-v3-coproc.c b/arch/arm/kvm/vgic-v3-coproc.c
deleted file mode 100644
index ed3b2e4759ce..000000000000
--
2.20.1
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 30+ messages in thread* [RFC PATCH 4/5] arm: Remove HYP/Stage-2 page-table support
2020-02-10 14:13 ` [RFC PATCH 0/5] Removing support for 32bit KVM/arm host Marc Zyngier
` (2 preceding siblings ...)
2020-02-10 14:13 ` [RFC PATCH 3/5] arm: Remove 32bit KVM host support Marc Zyngier
@ 2020-02-10 14:13 ` Marc Zyngier
2020-02-10 14:13 ` [RFC PATCH 5/5] arm: Remove GICv3 vgic compatibility macros Marc Zyngier
` (12 subsequent siblings)
16 siblings, 0 replies; 30+ messages in thread
From: Marc Zyngier @ 2020-02-10 14:13 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, kvm
Cc: Anders Berg, Russell King, Arnd Bergmann, Paolo Bonzini, Will Deacon
Remove all traces of Stage-2 and HYP page table support.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
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 | 7 -------
arch/arm/kernel/vmlinux-xip.lds.S | 8 --------
arch/arm/kernel/vmlinux.lds.S | 8 --------
arch/arm/kernel/vmlinux.lds.h | 10 ----------
arch/arm/mm/mmu.c | 26 --------------------------
8 files changed, 1 insertion(+), 93 deletions(-)
diff --git a/arch/arm/include/asm/pgtable-3level.h b/arch/arm/include/asm/pgtable-3level.h
index ad55ab068dbf..36805f94939e 100644
--- a/arch/arm/include/asm/pgtable-3level.h
+++ b/arch/arm/include/asm/pgtable-3level.h
@@ -104,26 +104,6 @@
*/
#define L_PGD_SWAPPER (_AT(pgdval_t, 1) << 55) /* swapper_pg_dir entry */
-/*
- * 2nd stage PTE definitions for LPAE.
- */
-#define L_PTE_S2_MT_UNCACHED (_AT(pteval_t, 0x0) << 2) /* strongly ordered */
-#define L_PTE_S2_MT_WRITETHROUGH (_AT(pteval_t, 0xa) << 2) /* normal inner write-through */
-#define L_PTE_S2_MT_WRITEBACK (_AT(pteval_t, 0xf) << 2) /* normal inner write-back */
-#define L_PTE_S2_MT_DEV_SHARED (_AT(pteval_t, 0x1) << 2) /* device */
-#define L_PTE_S2_MT_MASK (_AT(pteval_t, 0xf) << 2)
-
-#define L_PTE_S2_RDONLY (_AT(pteval_t, 1) << 6) /* HAP[1] */
-#define L_PTE_S2_RDWR (_AT(pteval_t, 3) << 6) /* HAP[2:1] */
-
-#define L_PMD_S2_RDONLY (_AT(pmdval_t, 1) << 6) /* HAP[1] */
-#define L_PMD_S2_RDWR (_AT(pmdval_t, 3) << 6) /* HAP[2:1] */
-
-/*
- * Hyp-mode PL2 PTE definitions for LPAE.
- */
-#define L_PTE_HYP L_PTE_USER
-
#ifndef __ASSEMBLY__
#define pud_none(pud) (!pud_val(pud))
diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
index eabcb48a7840..0483cf413315 100644
--- a/arch/arm/include/asm/pgtable.h
+++ b/arch/arm/include/asm/pgtable.h
@@ -80,9 +80,6 @@ extern void __pgd_error(const char *file, int line, pgd_t);
extern pgprot_t pgprot_user;
extern pgprot_t pgprot_kernel;
-extern pgprot_t pgprot_hyp_device;
-extern pgprot_t pgprot_s2;
-extern pgprot_t pgprot_s2_device;
#define _MOD_PROT(p, b) __pgprot(pgprot_val(p) | (b))
@@ -95,12 +92,6 @@ extern pgprot_t pgprot_s2_device;
#define PAGE_READONLY_EXEC _MOD_PROT(pgprot_user, L_PTE_USER | L_PTE_RDONLY)
#define PAGE_KERNEL _MOD_PROT(pgprot_kernel, L_PTE_XN)
#define PAGE_KERNEL_EXEC pgprot_kernel
-#define PAGE_HYP _MOD_PROT(pgprot_kernel, L_PTE_HYP | L_PTE_XN)
-#define PAGE_HYP_EXEC _MOD_PROT(pgprot_kernel, L_PTE_HYP | L_PTE_RDONLY)
-#define PAGE_HYP_RO _MOD_PROT(pgprot_kernel, L_PTE_HYP | L_PTE_RDONLY | L_PTE_XN)
-#define PAGE_HYP_DEVICE _MOD_PROT(pgprot_hyp_device, L_PTE_HYP)
-#define PAGE_S2 _MOD_PROT(pgprot_s2, L_PTE_S2_RDONLY | L_PTE_XN)
-#define PAGE_S2_DEVICE _MOD_PROT(pgprot_s2_device, L_PTE_S2_RDONLY | L_PTE_XN)
#define __PAGE_NONE __pgprot(_L_PTE_DEFAULT | L_PTE_RDONLY | L_PTE_XN | L_PTE_NONE)
#define __PAGE_SHARED __pgprot(_L_PTE_DEFAULT | L_PTE_USER | L_PTE_XN)
diff --git a/arch/arm/include/asm/sections.h b/arch/arm/include/asm/sections.h
index 4ceb4f757d4d..700b8bcdf9bd 100644
--- a/arch/arm/include/asm/sections.h
+++ b/arch/arm/include/asm/sections.h
@@ -10,8 +10,6 @@ extern char __idmap_text_start[];
extern char __idmap_text_end[];
extern char __entry_text_start[];
extern char __entry_text_end[];
-extern char __hyp_idmap_text_start[];
-extern char __hyp_idmap_text_end[];
static inline bool in_entry_text(unsigned long addr)
{
@@ -22,9 +20,7 @@ static inline bool in_entry_text(unsigned long addr)
static inline bool in_idmap_text(unsigned long addr)
{
void *a = (void *)addr;
- return memory_contains(__idmap_text_start, __idmap_text_end, a, 1) ||
- memory_contains(__hyp_idmap_text_start, __hyp_idmap_text_end,
- a, 1);
+ return memory_contains(__idmap_text_start, __idmap_text_end, a, 1);
}
#endif /* _ASM_ARM_SECTIONS_H */
diff --git a/arch/arm/include/asm/virt.h b/arch/arm/include/asm/virt.h
index 6cd4e33418e9..47600a5894b1 100644
--- a/arch/arm/include/asm/virt.h
+++ b/arch/arm/include/asm/virt.h
@@ -67,13 +67,6 @@ static inline bool is_kernel_in_hyp_mode(void)
return false;
}
-/* The section containing the hypervisor idmap text */
-extern char __hyp_idmap_text_start[];
-extern char __hyp_idmap_text_end[];
-
-/* The section containing the hypervisor text */
-extern char __hyp_text_start[];
-extern char __hyp_text_end[];
#endif
#else
diff --git a/arch/arm/kernel/vmlinux-xip.lds.S b/arch/arm/kernel/vmlinux-xip.lds.S
index 21b8b271c80d..6d2be994ae58 100644
--- a/arch/arm/kernel/vmlinux-xip.lds.S
+++ b/arch/arm/kernel/vmlinux-xip.lds.S
@@ -162,14 +162,6 @@ SECTIONS
ASSERT((__proc_info_end - __proc_info_begin), "missing CPU support")
ASSERT((__arch_info_end - __arch_info_begin), "no machine record defined")
-/*
- * The HYP init code can't be more than a page long,
- * and should not cross a page boundary.
- * The above comment applies as well.
- */
-ASSERT(__hyp_idmap_text_end - (__hyp_idmap_text_start & PAGE_MASK) <= PAGE_SIZE,
- "HYP init code too big or misaligned")
-
#ifdef CONFIG_XIP_DEFLATED_DATA
/*
* The .bss is used as a stack area for __inflate_kernel_data() whose stack
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 319ccb10846a..88a720da443b 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -170,12 +170,4 @@ __start_rodata_section_aligned = ALIGN(__start_rodata, 1 << SECTION_SHIFT);
ASSERT((__proc_info_end - __proc_info_begin), "missing CPU support")
ASSERT((__arch_info_end - __arch_info_begin), "no machine record defined")
-/*
- * The HYP init code can't be more than a page long,
- * and should not cross a page boundary.
- * The above comment applies as well.
- */
-ASSERT(__hyp_idmap_text_end - (__hyp_idmap_text_start & PAGE_MASK) <= PAGE_SIZE,
- "HYP init code too big or misaligned")
-
#endif /* CONFIG_XIP_KERNEL */
diff --git a/arch/arm/kernel/vmlinux.lds.h b/arch/arm/kernel/vmlinux.lds.h
index 8247bc15addc..381a8e105fa5 100644
--- a/arch/arm/kernel/vmlinux.lds.h
+++ b/arch/arm/kernel/vmlinux.lds.h
@@ -31,20 +31,11 @@
*(.proc.info.init) \
__proc_info_end = .;
-#define HYPERVISOR_TEXT \
- __hyp_text_start = .; \
- *(.hyp.text) \
- __hyp_text_end = .;
-
#define IDMAP_TEXT \
ALIGN_FUNCTION(); \
__idmap_text_start = .; \
*(.idmap.text) \
__idmap_text_end = .; \
- . = ALIGN(PAGE_SIZE); \
- __hyp_idmap_text_start = .; \
- *(.hyp.idmap.text) \
- __hyp_idmap_text_end = .;
#define ARM_DISCARD \
*(.ARM.exidx.exit.text) \
@@ -72,7 +63,6 @@
SCHED_TEXT \
CPUIDLE_TEXT \
LOCK_TEXT \
- HYPERVISOR_TEXT \
KPROBES_TEXT \
*(.gnu.warning) \
*(.glue_7) \
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 5d0d0f86e790..69a337df619f 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -63,9 +63,6 @@ static unsigned int cachepolicy __initdata = CPOLICY_WRITEBACK;
static unsigned int ecc_mask __initdata = 0;
pgprot_t pgprot_user;
pgprot_t pgprot_kernel;
-pgprot_t pgprot_hyp_device;
-pgprot_t pgprot_s2;
-pgprot_t pgprot_s2_device;
EXPORT_SYMBOL(pgprot_user);
EXPORT_SYMBOL(pgprot_kernel);
@@ -75,15 +72,8 @@ struct cachepolicy {
unsigned int cr_mask;
pmdval_t pmd;
pteval_t pte;
- pteval_t pte_s2;
};
-#ifdef CONFIG_ARM_LPAE
-#define s2_policy(policy) policy
-#else
-#define s2_policy(policy) 0
-#endif
-
unsigned long kimage_voffset __ro_after_init;
static struct cachepolicy cache_policies[] __initdata = {
@@ -92,31 +82,26 @@ static struct cachepolicy cache_policies[] __initdata = {
.cr_mask = CR_W|CR_C,
.pmd = PMD_SECT_UNCACHED,
.pte = L_PTE_MT_UNCACHED,
- .pte_s2 = s2_policy(L_PTE_S2_MT_UNCACHED),
}, {
.policy = "buffered",
.cr_mask = CR_C,
.pmd = PMD_SECT_BUFFERED,
.pte = L_PTE_MT_BUFFERABLE,
- .pte_s2 = s2_policy(L_PTE_S2_MT_UNCACHED),
}, {
.policy = "writethrough",
.cr_mask = 0,
.pmd = PMD_SECT_WT,
.pte = L_PTE_MT_WRITETHROUGH,
- .pte_s2 = s2_policy(L_PTE_S2_MT_WRITETHROUGH),
}, {
.policy = "writeback",
.cr_mask = 0,
.pmd = PMD_SECT_WB,
.pte = L_PTE_MT_WRITEBACK,
- .pte_s2 = s2_policy(L_PTE_S2_MT_WRITEBACK),
}, {
.policy = "writealloc",
.cr_mask = 0,
.pmd = PMD_SECT_WBWA,
.pte = L_PTE_MT_WRITEALLOC,
- .pte_s2 = s2_policy(L_PTE_S2_MT_WRITEBACK),
}
};
@@ -246,9 +231,6 @@ static struct mem_type mem_types[] __ro_after_init = {
[MT_DEVICE] = { /* Strongly ordered / ARMv6 shared device */
.prot_pte = PROT_PTE_DEVICE | L_PTE_MT_DEV_SHARED |
L_PTE_SHARED,
- .prot_pte_s2 = s2_policy(PROT_PTE_S2_DEVICE) |
- s2_policy(L_PTE_S2_MT_DEV_SHARED) |
- L_PTE_SHARED,
.prot_l1 = PMD_TYPE_TABLE,
.prot_sect = PROT_SECT_DEVICE | PMD_SECT_S,
.domain = DOMAIN_IO,
@@ -434,7 +416,6 @@ static void __init build_mem_type_table(void)
struct cachepolicy *cp;
unsigned int cr = get_cr();
pteval_t user_pgprot, kern_pgprot, vecs_pgprot;
- pteval_t hyp_device_pgprot, s2_pgprot, s2_device_pgprot;
int cpu_arch = cpu_architecture();
int i;
@@ -558,9 +539,6 @@ static void __init build_mem_type_table(void)
*/
cp = &cache_policies[cachepolicy];
vecs_pgprot = kern_pgprot = user_pgprot = cp->pte;
- s2_pgprot = cp->pte_s2;
- hyp_device_pgprot = mem_types[MT_DEVICE].prot_pte;
- s2_device_pgprot = mem_types[MT_DEVICE].prot_pte_s2;
#ifndef CONFIG_ARM_LPAE
/*
@@ -604,7 +582,6 @@ static void __init build_mem_type_table(void)
user_pgprot |= L_PTE_SHARED;
kern_pgprot |= L_PTE_SHARED;
vecs_pgprot |= L_PTE_SHARED;
- s2_pgprot |= L_PTE_SHARED;
mem_types[MT_DEVICE_WC].prot_sect |= PMD_SECT_S;
mem_types[MT_DEVICE_WC].prot_pte |= L_PTE_SHARED;
mem_types[MT_DEVICE_CACHED].prot_sect |= PMD_SECT_S;
@@ -666,9 +643,6 @@ static void __init build_mem_type_table(void)
pgprot_user = __pgprot(L_PTE_PRESENT | L_PTE_YOUNG | user_pgprot);
pgprot_kernel = __pgprot(L_PTE_PRESENT | L_PTE_YOUNG |
L_PTE_DIRTY | kern_pgprot);
- pgprot_s2 = __pgprot(L_PTE_PRESENT | L_PTE_YOUNG | s2_pgprot);
- pgprot_s2_device = __pgprot(s2_device_pgprot);
- pgprot_hyp_device = __pgprot(hyp_device_pgprot);
mem_types[MT_LOW_VECTORS].prot_l1 |= ecc_mask;
mem_types[MT_HIGH_VECTORS].prot_l1 |= ecc_mask;
--
2.20.1
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 30+ messages in thread* [RFC PATCH 5/5] arm: Remove GICv3 vgic compatibility macros
2020-02-10 14:13 ` [RFC PATCH 0/5] Removing support for 32bit KVM/arm host Marc Zyngier
` (3 preceding siblings ...)
2020-02-10 14:13 ` [RFC PATCH 4/5] arm: Remove HYP/Stage-2 page-table support Marc Zyngier
@ 2020-02-10 14:13 ` Marc Zyngier
2020-02-10 15:21 ` [RFC PATCH 0/5] Removing support for 32bit KVM/arm host Olof Johansson
` (11 subsequent siblings)
16 siblings, 0 replies; 30+ messages in thread
From: Marc Zyngier @ 2020-02-10 14:13 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, kvm
Cc: Anders Berg, Russell King, Arnd Bergmann, Paolo Bonzini, Will Deacon
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 <maz@kernel.org>
---
arch/arm/include/asm/arch_gicv3.h | 114 ------------------------------
1 file changed, 114 deletions(-)
diff --git a/arch/arm/include/asm/arch_gicv3.h b/arch/arm/include/asm/arch_gicv3.h
index c815477b4303..413abfb42989 100644
--- a/arch/arm/include/asm/arch_gicv3.h
+++ b/arch/arm/include/asm/arch_gicv3.h
@@ -38,71 +38,6 @@
#define ICC_AP1R2 __ICC_AP1Rx(2)
#define ICC_AP1R3 __ICC_AP1Rx(3)
-#define ICC_HSRE __ACCESS_CP15(c12, 4, c9, 5)
-
-#define ICH_VSEIR __ACCESS_CP15(c12, 4, c9, 4)
-#define ICH_HCR __ACCESS_CP15(c12, 4, c11, 0)
-#define ICH_VTR __ACCESS_CP15(c12, 4, c11, 1)
-#define ICH_MISR __ACCESS_CP15(c12, 4, c11, 2)
-#define ICH_EISR __ACCESS_CP15(c12, 4, c11, 3)
-#define ICH_ELRSR __ACCESS_CP15(c12, 4, c11, 5)
-#define ICH_VMCR __ACCESS_CP15(c12, 4, c11, 7)
-
-#define __LR0(x) __ACCESS_CP15(c12, 4, c12, x)
-#define __LR8(x) __ACCESS_CP15(c12, 4, c13, x)
-
-#define ICH_LR0 __LR0(0)
-#define ICH_LR1 __LR0(1)
-#define ICH_LR2 __LR0(2)
-#define ICH_LR3 __LR0(3)
-#define ICH_LR4 __LR0(4)
-#define ICH_LR5 __LR0(5)
-#define ICH_LR6 __LR0(6)
-#define ICH_LR7 __LR0(7)
-#define ICH_LR8 __LR8(0)
-#define ICH_LR9 __LR8(1)
-#define ICH_LR10 __LR8(2)
-#define ICH_LR11 __LR8(3)
-#define ICH_LR12 __LR8(4)
-#define ICH_LR13 __LR8(5)
-#define ICH_LR14 __LR8(6)
-#define ICH_LR15 __LR8(7)
-
-/* LR top half */
-#define __LRC0(x) __ACCESS_CP15(c12, 4, c14, x)
-#define __LRC8(x) __ACCESS_CP15(c12, 4, c15, x)
-
-#define ICH_LRC0 __LRC0(0)
-#define ICH_LRC1 __LRC0(1)
-#define ICH_LRC2 __LRC0(2)
-#define ICH_LRC3 __LRC0(3)
-#define ICH_LRC4 __LRC0(4)
-#define ICH_LRC5 __LRC0(5)
-#define ICH_LRC6 __LRC0(6)
-#define ICH_LRC7 __LRC0(7)
-#define ICH_LRC8 __LRC8(0)
-#define ICH_LRC9 __LRC8(1)
-#define ICH_LRC10 __LRC8(2)
-#define ICH_LRC11 __LRC8(3)
-#define ICH_LRC12 __LRC8(4)
-#define ICH_LRC13 __LRC8(5)
-#define ICH_LRC14 __LRC8(6)
-#define ICH_LRC15 __LRC8(7)
-
-#define __ICH_AP0Rx(x) __ACCESS_CP15(c12, 4, c8, x)
-#define ICH_AP0R0 __ICH_AP0Rx(0)
-#define ICH_AP0R1 __ICH_AP0Rx(1)
-#define ICH_AP0R2 __ICH_AP0Rx(2)
-#define ICH_AP0R3 __ICH_AP0Rx(3)
-
-#define __ICH_AP1Rx(x) __ACCESS_CP15(c12, 4, c9, x)
-#define ICH_AP1R0 __ICH_AP1Rx(0)
-#define ICH_AP1R1 __ICH_AP1Rx(1)
-#define ICH_AP1R2 __ICH_AP1Rx(2)
-#define ICH_AP1R3 __ICH_AP1Rx(3)
-
-/* A32-to-A64 mappings used by VGIC save/restore */
-
#define CPUIF_MAP(a32, a64) \
static inline void write_ ## a64(u32 val) \
{ \
@@ -113,21 +48,6 @@ static inline u32 read_ ## a64(void) \
return read_sysreg(a32); \
} \
-#define CPUIF_MAP_LO_HI(a32lo, a32hi, a64) \
-static inline void write_ ## a64(u64 val) \
-{ \
- write_sysreg(lower_32_bits(val), a32lo);\
- write_sysreg(upper_32_bits(val), a32hi);\
-} \
-static inline u64 read_ ## a64(void) \
-{ \
- u64 val = read_sysreg(a32lo); \
- \
- val |= (u64)read_sysreg(a32hi) << 32; \
- \
- return val; \
-}
-
CPUIF_MAP(ICC_PMR, ICC_PMR_EL1)
CPUIF_MAP(ICC_AP0R0, ICC_AP0R0_EL1)
CPUIF_MAP(ICC_AP0R1, ICC_AP0R1_EL1)
@@ -138,40 +58,6 @@ CPUIF_MAP(ICC_AP1R1, ICC_AP1R1_EL1)
CPUIF_MAP(ICC_AP1R2, ICC_AP1R2_EL1)
CPUIF_MAP(ICC_AP1R3, ICC_AP1R3_EL1)
-CPUIF_MAP(ICH_HCR, ICH_HCR_EL2)
-CPUIF_MAP(ICH_VTR, ICH_VTR_EL2)
-CPUIF_MAP(ICH_MISR, ICH_MISR_EL2)
-CPUIF_MAP(ICH_EISR, ICH_EISR_EL2)
-CPUIF_MAP(ICH_ELRSR, ICH_ELRSR_EL2)
-CPUIF_MAP(ICH_VMCR, ICH_VMCR_EL2)
-CPUIF_MAP(ICH_AP0R3, ICH_AP0R3_EL2)
-CPUIF_MAP(ICH_AP0R2, ICH_AP0R2_EL2)
-CPUIF_MAP(ICH_AP0R1, ICH_AP0R1_EL2)
-CPUIF_MAP(ICH_AP0R0, ICH_AP0R0_EL2)
-CPUIF_MAP(ICH_AP1R3, ICH_AP1R3_EL2)
-CPUIF_MAP(ICH_AP1R2, ICH_AP1R2_EL2)
-CPUIF_MAP(ICH_AP1R1, ICH_AP1R1_EL2)
-CPUIF_MAP(ICH_AP1R0, ICH_AP1R0_EL2)
-CPUIF_MAP(ICC_HSRE, ICC_SRE_EL2)
-CPUIF_MAP(ICC_SRE, ICC_SRE_EL1)
-
-CPUIF_MAP_LO_HI(ICH_LR15, ICH_LRC15, ICH_LR15_EL2)
-CPUIF_MAP_LO_HI(ICH_LR14, ICH_LRC14, ICH_LR14_EL2)
-CPUIF_MAP_LO_HI(ICH_LR13, ICH_LRC13, ICH_LR13_EL2)
-CPUIF_MAP_LO_HI(ICH_LR12, ICH_LRC12, ICH_LR12_EL2)
-CPUIF_MAP_LO_HI(ICH_LR11, ICH_LRC11, ICH_LR11_EL2)
-CPUIF_MAP_LO_HI(ICH_LR10, ICH_LRC10, ICH_LR10_EL2)
-CPUIF_MAP_LO_HI(ICH_LR9, ICH_LRC9, ICH_LR9_EL2)
-CPUIF_MAP_LO_HI(ICH_LR8, ICH_LRC8, ICH_LR8_EL2)
-CPUIF_MAP_LO_HI(ICH_LR7, ICH_LRC7, ICH_LR7_EL2)
-CPUIF_MAP_LO_HI(ICH_LR6, ICH_LRC6, ICH_LR6_EL2)
-CPUIF_MAP_LO_HI(ICH_LR5, ICH_LRC5, ICH_LR5_EL2)
-CPUIF_MAP_LO_HI(ICH_LR4, ICH_LRC4, ICH_LR4_EL2)
-CPUIF_MAP_LO_HI(ICH_LR3, ICH_LRC3, ICH_LR3_EL2)
-CPUIF_MAP_LO_HI(ICH_LR2, ICH_LRC2, ICH_LR2_EL2)
-CPUIF_MAP_LO_HI(ICH_LR1, ICH_LRC1, ICH_LR1_EL2)
-CPUIF_MAP_LO_HI(ICH_LR0, ICH_LRC0, ICH_LR0_EL2)
-
#define read_gicreg(r) read_##r()
#define write_gicreg(v, r) write_##r(v)
--
2.20.1
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
2020-02-10 14:13 ` [RFC PATCH 0/5] Removing support for 32bit KVM/arm host Marc Zyngier
` (4 preceding siblings ...)
2020-02-10 14:13 ` [RFC PATCH 5/5] arm: Remove GICv3 vgic compatibility macros Marc Zyngier
@ 2020-02-10 15:21 ` Olof Johansson
2020-02-10 15:54 ` Arnd Bergmann
2020-02-10 15:46 ` Will Deacon
` (10 subsequent siblings)
16 siblings, 1 reply; 30+ messages in thread
From: Olof Johansson @ 2020-02-10 15:21 UTC (permalink / raw)
To: Marc Zyngier
Cc: Anders Berg, Russell King, Arnd Bergmann, kvm, Paolo Bonzini,
Will Deacon, kvmarm, Linux ARM Mailing List
On Mon, Feb 10, 2020 at 3:13 PM Marc Zyngier <maz@kernel.org> 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:
>
> - It is incomplete (no debug support, no PMU)
> - It hasn't followed any of the architectural evolutions
> - It has zero users (I don't count myself here)
> - It is more and more getting in the way of new arm64 developments
>
> So here it is: unless someone screams and shows that they rely on
> KVM/arm to be maintained upsteam, I'll remove 32bit host support
> form the tree. One of the reasons that makes me confident nobody is
> using it is that I never receive *any* bug report. Yes, it is perfect.
> But if you depend on KVM/arm being available in mainline, please shout.
>
> To reiterate: 32bit guest support for arm64 stays, of course. Only
> 32bit host goes. Once this is merged, I plan to move virt/kvm/arm to
> arm64, and cleanup all the now unnecessary abstractions.
>
> The patches have been generated with the -D option to avoid spamming
> everyone with huge diffs, and there is a kvm-arm/goodbye branch in
> my kernel.org repository.
>
> Marc Zyngier (5):
> arm: Unplug KVM from the build system
> arm: Remove KVM from config files
> arm: Remove 32bit KVM host support
> arm: Remove HYP/Stage-2 page-table support
> arm: Remove GICv3 vgic compatibility macros
Since I'm generally happy to drop legacy code that has no users, with
the "if there are any significant users that speak up, I'll revoke my
support" caveat:
Acked-by: Olof Johansson <olof@lixom.net>
-Olof
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
2020-02-10 15:21 ` [RFC PATCH 0/5] Removing support for 32bit KVM/arm host Olof Johansson
@ 2020-02-10 15:54 ` Arnd Bergmann
0 siblings, 0 replies; 30+ messages in thread
From: Arnd Bergmann @ 2020-02-10 15:54 UTC (permalink / raw)
To: Olof Johansson
Cc: Anders Berg, Russell King, kvm list, Marc Zyngier, Paolo Bonzini,
Will Deacon, kvmarm, Linux ARM Mailing List
On Mon, Feb 10, 2020 at 4:32 PM Olof Johansson <olof@lixom.net> wrote:
> On Mon, Feb 10, 2020 at 3:13 PM Marc Zyngier <maz@kernel.org> 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:
> >
> > - It is incomplete (no debug support, no PMU)
> > - It hasn't followed any of the architectural evolutions
> > - It has zero users (I don't count myself here)
> > - It is more and more getting in the way of new arm64 developments
> >
> > So here it is: unless someone screams and shows that they rely on
> > KVM/arm to be maintained upsteam, I'll remove 32bit host support
> > form the tree. One of the reasons that makes me confident nobody is
> > using it is that I never receive *any* bug report. Yes, it is perfect.
> > But if you depend on KVM/arm being available in mainline, please shout.
> >
> > To reiterate: 32bit guest support for arm64 stays, of course. Only
> > 32bit host goes. Once this is merged, I plan to move virt/kvm/arm to
> > arm64, and cleanup all the now unnecessary abstractions.
I think this makes a lot of sense: we are seeing fewer new 32-bit
systems that have enough RAM to be a usable virtualization host,
as most new boards with more than 1GB of RAM typically pick 64-bit
SoCs, and on less than 1GB it gets awfully tight to do anything useful.
> Since I'm generally happy to drop legacy code that has no users, with
> the "if there are any significant users that speak up, I'll revoke my
> support" caveat:
>
> Acked-by: Olof Johansson <olof@lixom.net>
Same here
Acked-by: Arnd Bergmann <arnd@arndb.de>
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
2020-02-10 14:13 ` [RFC PATCH 0/5] Removing support for 32bit KVM/arm host Marc Zyngier
` (5 preceding siblings ...)
2020-02-10 15:21 ` [RFC PATCH 0/5] Removing support for 32bit KVM/arm host Olof Johansson
@ 2020-02-10 15:46 ` Will Deacon
2020-02-10 16:25 ` Russell King - ARM Linux admin
` (9 subsequent siblings)
16 siblings, 0 replies; 30+ messages in thread
From: Will Deacon @ 2020-02-10 15:46 UTC (permalink / raw)
To: Marc Zyngier
Cc: Anders Berg, Russell King, Arnd Bergmann, kvm, linux-arm-kernel,
Paolo Bonzini, kvmarm
On Mon, Feb 10, 2020 at 02:13:19PM +0000, 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:
>
> - It is incomplete (no debug support, no PMU)
> - It hasn't followed any of the architectural evolutions
> - It has zero users (I don't count myself here)
I tend to use it to test that it still works, but that's it.
> - It is more and more getting in the way of new arm64 developments
To echo this last point, we're currently looking at the possibility of
using KVM to isolate VMs from the host in Android. The scope of the
changes we think we'll have to make would mean effectively duplicating
the existing code for 32-bit or implementing a whole load of unused and
untested functionality to keep the current structure. Neither of these
options are particularly satisfactory from a maintainance point of view,
so removing the 32-bit code if it doesn't have any significant use would
be welcomed:
Acked-by: Will Deacon <will@kernel.org>
Will
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
2020-02-10 14:13 ` [RFC PATCH 0/5] Removing support for 32bit KVM/arm host Marc Zyngier
` (6 preceding siblings ...)
2020-02-10 15:46 ` Will Deacon
@ 2020-02-10 16:25 ` Russell King - ARM Linux admin
2020-02-10 16:26 ` Russell King - ARM Linux admin
2020-02-11 15:12 ` Vladimir Murzin
` (8 subsequent siblings)
16 siblings, 1 reply; 30+ messages in thread
From: Russell King - ARM Linux admin @ 2020-02-10 16:25 UTC (permalink / raw)
To: Marc Zyngier
Cc: Anders Berg, Arnd Bergmann, kvm, linux-arm-kernel, Paolo Bonzini,
Will Deacon, kvmarm
On Mon, Feb 10, 2020 at 02:13:19PM +0000, 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:
>
> - It is incomplete (no debug support, no PMU)
> - It hasn't followed any of the architectural evolutions
> - It has zero users (I don't count myself here)
> - It is more and more getting in the way of new arm64 developments
>
> So here it is: unless someone screams and shows that they rely on
> KVM/arm to be maintained upsteam, I'll remove 32bit host support
> form the tree. One of the reasons that makes me confident nobody is
> using it is that I never receive *any* bug report. Yes, it is perfect.
> But if you depend on KVM/arm being available in mainline, please shout.
It is only very recently that 64-bit ARM has really started to filter
down to people like me, and people like me have setup systems which
use 32-bit VMs under 64-bit hosts (about a year ago now.) In fact,
everything that you presently see for the *.armlinux.org.uk domain now
runs inside several 32-bit ARM VMs under a 64-bit ARM host.
It isn't perfect; I've found issues with qemu and libvirt. One example
is the rather sub-standard RTC implementation, which means if you
use libvirt's managesave across a host reboot, the guests idea of
time-of-day freezes while it's asleep, and resumes when the guest is
reloaded - resulting in the guests time-of-day being rather wrong,
sometimes to the point that NTP gives up. That becomes very painful
if you use kerberos authentication, where time-of-day is important.
So, just because you haven't received any bug reports doesn't mean
there aren't any users; there certainly are, there are problems,
but the problems are in places other than the kernel.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
2020-02-10 16:25 ` Russell King - ARM Linux admin
@ 2020-02-10 16:26 ` Russell King - ARM Linux admin
0 siblings, 0 replies; 30+ messages in thread
From: Russell King - ARM Linux admin @ 2020-02-10 16:26 UTC (permalink / raw)
To: Marc Zyngier
Cc: Anders Berg, Arnd Bergmann, kvm, linux-arm-kernel, Paolo Bonzini,
Will Deacon, kvmarm
On Mon, Feb 10, 2020 at 04:25:23PM +0000, Russell King - ARM Linux admin wrote:
> On Mon, Feb 10, 2020 at 02:13:19PM +0000, 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:
> >
> > - It is incomplete (no debug support, no PMU)
> > - It hasn't followed any of the architectural evolutions
> > - It has zero users (I don't count myself here)
> > - It is more and more getting in the way of new arm64 developments
> >
> > So here it is: unless someone screams and shows that they rely on
> > KVM/arm to be maintained upsteam, I'll remove 32bit host support
> > form the tree. One of the reasons that makes me confident nobody is
> > using it is that I never receive *any* bug report. Yes, it is perfect.
> > But if you depend on KVM/arm being available in mainline, please shout.
>
> It is only very recently that 64-bit ARM has really started to filter
> down to people like me, and people like me have setup systems which
> use 32-bit VMs under 64-bit hosts (about a year ago now.) In fact,
> everything that you presently see for the *.armlinux.org.uk domain now
> runs inside several 32-bit ARM VMs under a 64-bit ARM host.
>
> It isn't perfect; I've found issues with qemu and libvirt. One example
> is the rather sub-standard RTC implementation, which means if you
> use libvirt's managesave across a host reboot, the guests idea of
> time-of-day freezes while it's asleep, and resumes when the guest is
> reloaded - resulting in the guests time-of-day being rather wrong,
> sometimes to the point that NTP gives up. That becomes very painful
> if you use kerberos authentication, where time-of-day is important.
>
> So, just because you haven't received any bug reports doesn't mean
> there aren't any users; there certainly are, there are problems,
> but the problems are in places other than the kernel.
... argh, I see, you're not removing 32-bit guest on 64-bit. Ignore
the above then.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
2020-02-10 14:13 ` [RFC PATCH 0/5] Removing support for 32bit KVM/arm host Marc Zyngier
` (7 preceding siblings ...)
2020-02-10 16:25 ` Russell King - ARM Linux admin
@ 2020-02-11 15:12 ` Vladimir Murzin
2020-02-11 15:23 ` Catalin Marinas
` (7 subsequent siblings)
16 siblings, 0 replies; 30+ messages in thread
From: Vladimir Murzin @ 2020-02-11 15:12 UTC (permalink / raw)
To: Marc Zyngier, linux-arm-kernel, kvmarm, kvm
Cc: Anders Berg, Russell King, Arnd Bergmann, Paolo Bonzini, Will Deacon
On 2/10/20 2: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:
>
> - It is incomplete (no debug support, no PMU)
> - It hasn't followed any of the architectural evolutions
> - It has zero users (I don't count myself here)
> - It is more and more getting in the way of new arm64 developments
>
> So here it is: unless someone screams and shows that they rely on
> KVM/arm to be maintained upsteam, I'll remove 32bit host support
> form the tree. One of the reasons that makes me confident nobody is
> using it is that I never receive *any* bug report. Yes, it is perfect.
> But if you depend on KVM/arm being available in mainline, please shout.
>
> To reiterate: 32bit guest support for arm64 stays, of course. Only
> 32bit host goes. Once this is merged, I plan to move virt/kvm/arm to
> arm64, and cleanup all the now unnecessary abstractions.
>
> The patches have been generated with the -D option to avoid spamming
> everyone with huge diffs, and there is a kvm-arm/goodbye branch in
> my kernel.org repository.
>
> Marc Zyngier (5):
> arm: Unplug KVM from the build system
> arm: Remove KVM from config files
> arm: Remove 32bit KVM host support
> arm: Remove HYP/Stage-2 page-table support
> arm: Remove GICv3 vgic compatibility macros
Acked-by: Vladimir Murzin <vladimir.murzin@arm.com>
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
2020-02-10 14:13 ` [RFC PATCH 0/5] Removing support for 32bit KVM/arm host Marc Zyngier
` (8 preceding siblings ...)
2020-02-11 15:12 ` Vladimir Murzin
@ 2020-02-11 15:23 ` Catalin Marinas
2020-02-17 0:14 ` Linus Walleij
` (6 subsequent siblings)
16 siblings, 0 replies; 30+ messages in thread
From: Catalin Marinas @ 2020-02-11 15:23 UTC (permalink / raw)
To: Marc Zyngier
Cc: Anders Berg, Russell King, Arnd Bergmann, kvm, Paolo Bonzini,
Will Deacon, kvmarm, linux-arm-kernel
On Mon, Feb 10, 2020 at 02:13:19PM +0000, 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:
>
> - It is incomplete (no debug support, no PMU)
> - It hasn't followed any of the architectural evolutions
> - It has zero users (I don't count myself here)
> - It is more and more getting in the way of new arm64 developments
>
> So here it is: unless someone screams and shows that they rely on
> KVM/arm to be maintained upsteam, I'll remove 32bit host support
> form the tree. One of the reasons that makes me confident nobody is
> using it is that I never receive *any* bug report. Yes, it is perfect.
> But if you depend on KVM/arm being available in mainline, please shout.
>
> To reiterate: 32bit guest support for arm64 stays, of course. Only
> 32bit host goes. Once this is merged, I plan to move virt/kvm/arm to
> arm64, and cleanup all the now unnecessary abstractions.
>
> The patches have been generated with the -D option to avoid spamming
> everyone with huge diffs, and there is a kvm-arm/goodbye branch in
> my kernel.org repository.
>
> Marc Zyngier (5):
> arm: Unplug KVM from the build system
> arm: Remove KVM from config files
> arm: Remove 32bit KVM host support
> arm: Remove HYP/Stage-2 page-table support
> arm: Remove GICv3 vgic compatibility macros
FWIW:
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
2020-02-10 14:13 ` [RFC PATCH 0/5] Removing support for 32bit KVM/arm host Marc Zyngier
` (9 preceding siblings ...)
2020-02-11 15:23 ` Catalin Marinas
@ 2020-02-17 0:14 ` Linus Walleij
2020-02-19 13:53 ` Stefan Agner
` (5 subsequent siblings)
16 siblings, 0 replies; 30+ messages in thread
From: Linus Walleij @ 2020-02-17 0:14 UTC (permalink / raw)
To: Marc Zyngier
Cc: Anders Berg, Russell King, Arnd Bergmann, kvm, Paolo Bonzini,
Will Deacon, kvmarm, Linux ARM
On Mon, Feb 10, 2020 at 3:13 PM Marc Zyngier <maz@kernel.org> wrote:
> it has been a good prototype for the arm64 version,
> but it suffers a few problems:
Wittgenstein wrote that sometimes an intellectual exercise work like such
that you have to throw away the ladder after you climbed it. It often
happens in engineering.
It also echoes Fred Brooks Mythical Man-Month:
"In most projects, the first system built is barely usable....Hence plan to
throw one away; you will, anyhow."
> To reiterate: 32bit guest support for arm64 stays, of course. Only
> 32bit host goes.
That sounds more useful.
I won't miss it.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
2020-02-10 14:13 ` [RFC PATCH 0/5] Removing support for 32bit KVM/arm host Marc Zyngier
` (10 preceding siblings ...)
2020-02-17 0:14 ` Linus Walleij
@ 2020-02-19 13:53 ` Stefan Agner
2020-02-20 11:01 ` Marc Zyngier
2020-02-19 14:56 ` Christoffer Dall
` (4 subsequent siblings)
16 siblings, 1 reply; 30+ messages in thread
From: Stefan Agner @ 2020-02-19 13:53 UTC (permalink / raw)
To: Marc Zyngier
Cc: Anders Berg, Russell King, Arnd Bergmann, kvm, Paolo Bonzini,
Will Deacon, kvmarm, linux-arm-kernel
On 2020-02-10 15:13, 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:
>
> - It is incomplete (no debug support, no PMU)
> - It hasn't followed any of the architectural evolutions
> - It has zero users (I don't count myself here)
> - It is more and more getting in the way of new arm64 developments
>
> So here it is: unless someone screams and shows that they rely on
> KVM/arm to be maintained upsteam, I'll remove 32bit host support
> form the tree. One of the reasons that makes me confident nobody is
> using it is that I never receive *any* bug report. Yes, it is perfect.
Not entirely true:
https://lore.kernel.org/m/e2f7196ca6c70c55463a45b490f6731a@agner.ch
But, after that was fixed, it actually was perfect :-D
https://blog.printk.io/2016/09/kvm-with-kvmtool-on-armv7/
That said, I never used it in a real-world application, so from my side
removing it is fine.
--
Stefan
> But if you depend on KVM/arm being available in mainline, please shout.
>
> To reiterate: 32bit guest support for arm64 stays, of course. Only
> 32bit host goes. Once this is merged, I plan to move virt/kvm/arm to
> arm64, and cleanup all the now unnecessary abstractions.
>
> The patches have been generated with the -D option to avoid spamming
> everyone with huge diffs, and there is a kvm-arm/goodbye branch in
> my kernel.org repository.
>
> Marc Zyngier (5):
> arm: Unplug KVM from the build system
> arm: Remove KVM from config files
> arm: Remove 32bit KVM host support
> arm: Remove HYP/Stage-2 page-table support
> arm: Remove GICv3 vgic compatibility macros
>
> Documentation/virt/kvm/arm/hyp-abi.txt | 5 +
> arch/arm/Kconfig | 2 -
> arch/arm/Makefile | 1 -
> arch/arm/configs/axm55xx_defconfig | 2 -
> arch/arm/include/asm/arch_gicv3.h | 114 --
> arch/arm/include/asm/kvm_arm.h | 239 ----
> arch/arm/include/asm/kvm_asm.h | 77 --
> arch/arm/include/asm/kvm_coproc.h | 36 -
> arch/arm/include/asm/kvm_emulate.h | 372 ------
> arch/arm/include/asm/kvm_host.h | 459 --------
> arch/arm/include/asm/kvm_hyp.h | 127 ---
> arch/arm/include/asm/kvm_mmu.h | 435 -------
> arch/arm/include/asm/kvm_ras.h | 14 -
> 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/stage2_pgtable.h | 75 --
> arch/arm/include/asm/virt.h | 12 -
> arch/arm/include/uapi/asm/kvm.h | 314 -----
> arch/arm/kernel/asm-offsets.c | 11 -
> arch/arm/kernel/vmlinux-xip.lds.S | 8 -
> arch/arm/kernel/vmlinux.lds.S | 8 -
> arch/arm/kernel/vmlinux.lds.h | 10 -
> arch/arm/kvm/Kconfig | 59 -
> arch/arm/kvm/Makefile | 43 -
> arch/arm/kvm/coproc.c | 1455 ------------------------
> arch/arm/kvm/coproc.h | 130 ---
> arch/arm/kvm/coproc_a15.c | 39 -
> arch/arm/kvm/coproc_a7.c | 42 -
> arch/arm/kvm/emulate.c | 166 ---
> arch/arm/kvm/guest.c | 387 -------
> arch/arm/kvm/handle_exit.c | 175 ---
> arch/arm/kvm/hyp/Makefile | 34 -
> arch/arm/kvm/hyp/banked-sr.c | 70 --
> arch/arm/kvm/hyp/cp15-sr.c | 72 --
> arch/arm/kvm/hyp/entry.S | 121 --
> arch/arm/kvm/hyp/hyp-entry.S | 295 -----
> arch/arm/kvm/hyp/s2-setup.c | 22 -
> arch/arm/kvm/hyp/switch.c | 242 ----
> arch/arm/kvm/hyp/tlb.c | 68 --
> arch/arm/kvm/hyp/vfp.S | 57 -
> arch/arm/kvm/init.S | 157 ---
> arch/arm/kvm/interrupts.S | 36 -
> arch/arm/kvm/irq.h | 16 -
> arch/arm/kvm/reset.c | 86 --
> arch/arm/kvm/trace.h | 86 --
> arch/arm/kvm/vgic-v3-coproc.c | 27 -
> arch/arm/mach-exynos/Kconfig | 2 +-
> arch/arm/mm/mmu.c | 26 -
> 49 files changed, 7 insertions(+), 6262 deletions(-)
> delete mode 100644 arch/arm/include/asm/kvm_arm.h
> delete mode 100644 arch/arm/include/asm/kvm_asm.h
> delete mode 100644 arch/arm/include/asm/kvm_coproc.h
> delete mode 100644 arch/arm/include/asm/kvm_emulate.h
> delete mode 100644 arch/arm/include/asm/kvm_host.h
> delete mode 100644 arch/arm/include/asm/kvm_hyp.h
> delete mode 100644 arch/arm/include/asm/kvm_mmu.h
> delete mode 100644 arch/arm/include/asm/kvm_ras.h
> delete mode 100644 arch/arm/include/asm/stage2_pgtable.h
> delete mode 100644 arch/arm/include/uapi/asm/kvm.h
> delete mode 100644 arch/arm/kvm/Kconfig
> delete mode 100644 arch/arm/kvm/Makefile
> delete mode 100644 arch/arm/kvm/coproc.c
> delete mode 100644 arch/arm/kvm/coproc.h
> delete mode 100644 arch/arm/kvm/coproc_a15.c
> delete mode 100644 arch/arm/kvm/coproc_a7.c
> delete mode 100644 arch/arm/kvm/emulate.c
> delete mode 100644 arch/arm/kvm/guest.c
> delete mode 100644 arch/arm/kvm/handle_exit.c
> delete mode 100644 arch/arm/kvm/hyp/Makefile
> delete mode 100644 arch/arm/kvm/hyp/banked-sr.c
> delete mode 100644 arch/arm/kvm/hyp/cp15-sr.c
> delete mode 100644 arch/arm/kvm/hyp/entry.S
> delete mode 100644 arch/arm/kvm/hyp/hyp-entry.S
> delete mode 100644 arch/arm/kvm/hyp/s2-setup.c
> delete mode 100644 arch/arm/kvm/hyp/switch.c
> delete mode 100644 arch/arm/kvm/hyp/tlb.c
> delete mode 100644 arch/arm/kvm/hyp/vfp.S
> delete mode 100644 arch/arm/kvm/init.S
> delete mode 100644 arch/arm/kvm/interrupts.S
> delete mode 100644 arch/arm/kvm/irq.h
> delete mode 100644 arch/arm/kvm/reset.c
> delete mode 100644 arch/arm/kvm/trace.h
> delete mode 100644 arch/arm/kvm/vgic-v3-coproc.c
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
2020-02-19 13:53 ` Stefan Agner
@ 2020-02-20 11:01 ` Marc Zyngier
0 siblings, 0 replies; 30+ messages in thread
From: Marc Zyngier @ 2020-02-20 11:01 UTC (permalink / raw)
To: Stefan Agner
Cc: Russell King, kvm, Arnd Bergmann, Paolo Bonzini, Will Deacon,
kvmarm, linux-arm-kernel
On 2020-02-19 13:53, Stefan Agner wrote:
> On 2020-02-10 15:13, 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:
>>
>> - It is incomplete (no debug support, no PMU)
>> - It hasn't followed any of the architectural evolutions
>> - It has zero users (I don't count myself here)
>> - It is more and more getting in the way of new arm64 developments
>>
>> So here it is: unless someone screams and shows that they rely on
>> KVM/arm to be maintained upsteam, I'll remove 32bit host support
>> form the tree. One of the reasons that makes me confident nobody is
>> using it is that I never receive *any* bug report. Yes, it is perfect.
>
> Not entirely true:
> https://lore.kernel.org/m/e2f7196ca6c70c55463a45b490f6731a@agner.ch
And I thank you for that. This bug was actually hitting both arm and
arm64, and triggered by a bogus DT (that KVM should have handled in a
nicer way). What I was trying to say is that nobody reports bugs that
are specific to 32bit KVM/arm.
> But, after that was fixed, it actually was perfect :-D
> https://blog.printk.io/2016/09/kvm-with-kvmtool-on-armv7/
Hey, neat! not sure how useful, but neat nonetheless... ;-)
> That said, I never used it in a real-world application, so from my side
> removing it is fine.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
2020-02-10 14:13 ` [RFC PATCH 0/5] Removing support for 32bit KVM/arm host Marc Zyngier
` (11 preceding siblings ...)
2020-02-19 13:53 ` Stefan Agner
@ 2020-02-19 14:56 ` Christoffer Dall
2020-02-19 15:09 ` Arnd Bergmann
` (3 subsequent siblings)
16 siblings, 0 replies; 30+ messages in thread
From: Christoffer Dall @ 2020-02-19 14:56 UTC (permalink / raw)
To: Marc Zyngier
Cc: Anders Berg, Russell King, Arnd Bergmann, kvm, linux-arm-kernel,
Paolo Bonzini, Will Deacon, kvmarm
On Mon, Feb 10, 2020 at 02:13:19PM +0000, 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:
>
> - It is incomplete (no debug support, no PMU)
> - It hasn't followed any of the architectural evolutions
> - It has zero users (I don't count myself here)
> - It is more and more getting in the way of new arm64 developments
>
> So here it is: unless someone screams and shows that they rely on
> KVM/arm to be maintained upsteam, I'll remove 32bit host support
> form the tree. One of the reasons that makes me confident nobody is
> using it is that I never receive *any* bug report. Yes, it is perfect.
> But if you depend on KVM/arm being available in mainline, please shout.
>
> To reiterate: 32bit guest support for arm64 stays, of course. Only
> 32bit host goes. Once this is merged, I plan to move virt/kvm/arm to
> arm64, and cleanup all the now unnecessary abstractions.
>
> The patches have been generated with the -D option to avoid spamming
> everyone with huge diffs, and there is a kvm-arm/goodbye branch in
> my kernel.org repository.
Acked-by: Christoffer Dall <christoffer.dall@arm.com>
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
2020-02-10 14:13 ` [RFC PATCH 0/5] Removing support for 32bit KVM/arm host Marc Zyngier
` (12 preceding siblings ...)
2020-02-19 14:56 ` Christoffer Dall
@ 2020-02-19 15:09 ` Arnd Bergmann
2020-02-19 15:46 ` Jan Kiszka
2020-02-20 12:44 ` Marek Szyprowski
` (2 subsequent siblings)
16 siblings, 1 reply; 30+ messages in thread
From: Arnd Bergmann @ 2020-02-19 15:09 UTC (permalink / raw)
To: Marc Zyngier
Cc: jailhouse-dev, Anders Berg, Russell King, kvm list,
jean-philippe.brucker, Jan Kiszka, Linux ARM, Paolo Bonzini,
Will Deacon, kvmarm
On Mon, Feb 10, 2020 at 3:13 PM Marc Zyngier <maz@kernel.org> 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:
>
> - It is incomplete (no debug support, no PMU)
> - It hasn't followed any of the architectural evolutions
> - It has zero users (I don't count myself here)
> - It is more and more getting in the way of new arm64 developments
>
> So here it is: unless someone screams and shows that they rely on
> KVM/arm to be maintained upsteam, I'll remove 32bit host support
> form the tree. One of the reasons that makes me confident nobody is
> using it is that I never receive *any* bug report. Yes, it is perfect.
> But if you depend on KVM/arm being available in mainline, please shout.
>
> To reiterate: 32bit guest support for arm64 stays, of course. Only
> 32bit host goes. Once this is merged, I plan to move virt/kvm/arm to
> arm64, and cleanup all the now unnecessary abstractions.
>
> The patches have been generated with the -D option to avoid spamming
> everyone with huge diffs, and there is a kvm-arm/goodbye branch in
> my kernel.org repository.
Just one more thought before it's gone: is there any shared code
(header files?) that is used by the jailhouse hypervisor?
If there is, are there any plans to merge that into the mainline kernel
for arm32 in the near future?
I'm guessing the answer to at least one of those questions is 'no', so
we don't need to worry about it, but it seems better to ask.
Arnd
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
2020-02-19 15:09 ` Arnd Bergmann
@ 2020-02-19 15:46 ` Jan Kiszka
2020-02-20 10:29 ` Marc Zyngier
0 siblings, 1 reply; 30+ messages in thread
From: Jan Kiszka @ 2020-02-19 15:46 UTC (permalink / raw)
To: Arnd Bergmann, Marc Zyngier
Cc: jailhouse-dev, Anders Berg, Russell King, kvm list,
jean-philippe.brucker, Linux ARM, Paolo Bonzini, Will Deacon,
kvmarm
On 19.02.20 16:09, Arnd Bergmann wrote:
> On Mon, Feb 10, 2020 at 3:13 PM Marc Zyngier <maz@kernel.org> 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:
>>
>> - It is incomplete (no debug support, no PMU)
>> - It hasn't followed any of the architectural evolutions
>> - It has zero users (I don't count myself here)
>> - It is more and more getting in the way of new arm64 developments
>>
>> So here it is: unless someone screams and shows that they rely on
>> KVM/arm to be maintained upsteam, I'll remove 32bit host support
>> form the tree. One of the reasons that makes me confident nobody is
>> using it is that I never receive *any* bug report. Yes, it is perfect.
>> But if you depend on KVM/arm being available in mainline, please shout.
>>
>> To reiterate: 32bit guest support for arm64 stays, of course. Only
>> 32bit host goes. Once this is merged, I plan to move virt/kvm/arm to
>> arm64, and cleanup all the now unnecessary abstractions.
>>
>> The patches have been generated with the -D option to avoid spamming
>> everyone with huge diffs, and there is a kvm-arm/goodbye branch in
>> my kernel.org repository.
>
> Just one more thought before it's gone: is there any shared code
> (header files?) that is used by the jailhouse hypervisor?
>
> If there is, are there any plans to merge that into the mainline kernel
> for arm32 in the near future?
>
> I'm guessing the answer to at least one of those questions is 'no', so
> we don't need to worry about it, but it seems better to ask.
Good that you mention it: There is one thing we share on ARM (and
ARM64), and that is the hypervisor enabling stub, to install our own
vectors. If that was to be removed as well, we would have to patch it
back downstream. So far, we only carry few EXPORT_SYMBOL patches for
essential enabling.
That said, I was also starting to think about how long we will continue
to support Jailhouse on 32-bit ARM. We currently have no supported SoC
there that comes with an SMMU, and I doubt to see one still showing up.
So, Jailhouse on ARM is really just a testing/demo case, maybe useful
(but I didn't get concrete feedback) for cleaner collaborative AMP for
real-time purposes, without security concerns. I assume 32-bit ARM will
never be part of what would be proposed of Jailhouse for upstream.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
2020-02-19 15:46 ` Jan Kiszka
@ 2020-02-20 10:29 ` Marc Zyngier
0 siblings, 0 replies; 30+ messages in thread
From: Marc Zyngier @ 2020-02-20 10:29 UTC (permalink / raw)
To: Jan Kiszka
Cc: jailhouse-dev, Anders Berg, Russell King, Arnd Bergmann,
kvm list, jean-philippe.brucker, Linux ARM, Paolo Bonzini,
Will Deacon, kvmarm
On 2020-02-19 15:46, Jan Kiszka wrote:
> On 19.02.20 16:09, Arnd Bergmann wrote:
>> On Mon, Feb 10, 2020 at 3:13 PM Marc Zyngier <maz@kernel.org> 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:
>>>
>>> - It is incomplete (no debug support, no PMU)
>>> - It hasn't followed any of the architectural evolutions
>>> - It has zero users (I don't count myself here)
>>> - It is more and more getting in the way of new arm64 developments
>>>
>>> So here it is: unless someone screams and shows that they rely on
>>> KVM/arm to be maintained upsteam, I'll remove 32bit host support
>>> form the tree. One of the reasons that makes me confident nobody is
>>> using it is that I never receive *any* bug report. Yes, it is
>>> perfect.
>>> But if you depend on KVM/arm being available in mainline, please
>>> shout.
>>>
>>> To reiterate: 32bit guest support for arm64 stays, of course. Only
>>> 32bit host goes. Once this is merged, I plan to move virt/kvm/arm to
>>> arm64, and cleanup all the now unnecessary abstractions.
>>>
>>> The patches have been generated with the -D option to avoid spamming
>>> everyone with huge diffs, and there is a kvm-arm/goodbye branch in
>>> my kernel.org repository.
>>
>> Just one more thought before it's gone: is there any shared code
>> (header files?) that is used by the jailhouse hypervisor?
>>
>> If there is, are there any plans to merge that into the mainline
>> kernel
>> for arm32 in the near future?
>>
>> I'm guessing the answer to at least one of those questions is 'no', so
>> we don't need to worry about it, but it seems better to ask.
>
> Good that you mention it: There is one thing we share on ARM (and
> ARM64), and that is the hypervisor enabling stub, to install our own
> vectors. If that was to be removed as well, we would have to patch it
> back downstream. So far, we only carry few EXPORT_SYMBOL patches for
> essential enabling.
I actually have a few extra patches on top of the series, one of them
actually removing the ability to register new vectors (mostly because
I don't like leaving unused stuff behind), see [1]. I'll post an update
so that we can discuss whether we want this particular to stay or not.
> That said, I was also starting to think about how long we will
> continue to support Jailhouse on 32-bit ARM. We currently have no
> supported SoC there that comes with an SMMU, and I doubt to see one
> still showing up. So, Jailhouse on ARM is really just a testing/demo
> case, maybe useful (but I didn't get concrete feedback) for cleaner
> collaborative AMP for real-time purposes, without security concerns. I
> assume 32-bit ARM will never be part of what would be proposed of
> Jailhouse for upstream.
I guess we all come to the same conclusion...
M.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=kvm-arm/goodbye&id=0943dd119105b65197adffda52c402cce28da56d
--
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
2020-02-10 14:13 ` [RFC PATCH 0/5] Removing support for 32bit KVM/arm host Marc Zyngier
` (13 preceding siblings ...)
2020-02-19 15:09 ` Arnd Bergmann
@ 2020-02-20 12:44 ` Marek Szyprowski
2020-02-20 13:15 ` Marc Zyngier
2020-02-22 14:21 ` Takashi Yoshi
2020-02-22 14:40 ` Takashi Yoshi
16 siblings, 1 reply; 30+ messages in thread
From: Marek Szyprowski @ 2020-02-20 12:44 UTC (permalink / raw)
To: Marc Zyngier, linux-arm-kernel, kvmarm, kvm
Cc: Anders Berg, Russell King, Arnd Bergmann, Krzysztof Kozlowski,
Bartlomiej Zolnierkiewicz, Paolo Bonzini, Will Deacon
Hi Marc,
On 10.02.2020 15:13, 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:
>
> - It is incomplete (no debug support, no PMU)
> - It hasn't followed any of the architectural evolutions
> - It has zero users (I don't count myself here)
> - It is more and more getting in the way of new arm64 developments
That is a bit sad information. Mainline Exynos finally got everything
that was needed to run it on the quite popular Samsung Exynos5422-based
Odroid XU4/HC1/MC1 boards. According to the Odroid related forums it is
being used. We also use it internally at Samsung.
> So here it is: unless someone screams and shows that they rely on
> KVM/arm to be maintained upsteam, I'll remove 32bit host support
> form the tree. One of the reasons that makes me confident nobody is
> using it is that I never receive *any* bug report. Yes, it is perfect.
> But if you depend on KVM/arm being available in mainline, please shout.
>
> To reiterate: 32bit guest support for arm64 stays, of course. Only
> 32bit host goes. Once this is merged, I plan to move virt/kvm/arm to
> arm64, and cleanup all the now unnecessary abstractions.
>
> The patches have been generated with the -D option to avoid spamming
> everyone with huge diffs, and there is a kvm-arm/goodbye branch in
> my kernel.org repository.
>
> Marc Zyngier (5):
> arm: Unplug KVM from the build system
> arm: Remove KVM from config files
> arm: Remove 32bit KVM host support
> arm: Remove HYP/Stage-2 page-table support
> arm: Remove GICv3 vgic compatibility macros
>
> Documentation/virt/kvm/arm/hyp-abi.txt | 5 +
> arch/arm/Kconfig | 2 -
> arch/arm/Makefile | 1 -
> arch/arm/configs/axm55xx_defconfig | 2 -
> arch/arm/include/asm/arch_gicv3.h | 114 --
> arch/arm/include/asm/kvm_arm.h | 239 ----
> arch/arm/include/asm/kvm_asm.h | 77 --
> arch/arm/include/asm/kvm_coproc.h | 36 -
> arch/arm/include/asm/kvm_emulate.h | 372 ------
> arch/arm/include/asm/kvm_host.h | 459 --------
> arch/arm/include/asm/kvm_hyp.h | 127 ---
> arch/arm/include/asm/kvm_mmu.h | 435 -------
> arch/arm/include/asm/kvm_ras.h | 14 -
> 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/stage2_pgtable.h | 75 --
> arch/arm/include/asm/virt.h | 12 -
> arch/arm/include/uapi/asm/kvm.h | 314 -----
> arch/arm/kernel/asm-offsets.c | 11 -
> arch/arm/kernel/vmlinux-xip.lds.S | 8 -
> arch/arm/kernel/vmlinux.lds.S | 8 -
> arch/arm/kernel/vmlinux.lds.h | 10 -
> arch/arm/kvm/Kconfig | 59 -
> arch/arm/kvm/Makefile | 43 -
> arch/arm/kvm/coproc.c | 1455 ------------------------
> arch/arm/kvm/coproc.h | 130 ---
> arch/arm/kvm/coproc_a15.c | 39 -
> arch/arm/kvm/coproc_a7.c | 42 -
> arch/arm/kvm/emulate.c | 166 ---
> arch/arm/kvm/guest.c | 387 -------
> arch/arm/kvm/handle_exit.c | 175 ---
> arch/arm/kvm/hyp/Makefile | 34 -
> arch/arm/kvm/hyp/banked-sr.c | 70 --
> arch/arm/kvm/hyp/cp15-sr.c | 72 --
> arch/arm/kvm/hyp/entry.S | 121 --
> arch/arm/kvm/hyp/hyp-entry.S | 295 -----
> arch/arm/kvm/hyp/s2-setup.c | 22 -
> arch/arm/kvm/hyp/switch.c | 242 ----
> arch/arm/kvm/hyp/tlb.c | 68 --
> arch/arm/kvm/hyp/vfp.S | 57 -
> arch/arm/kvm/init.S | 157 ---
> arch/arm/kvm/interrupts.S | 36 -
> arch/arm/kvm/irq.h | 16 -
> arch/arm/kvm/reset.c | 86 --
> arch/arm/kvm/trace.h | 86 --
> arch/arm/kvm/vgic-v3-coproc.c | 27 -
> arch/arm/mach-exynos/Kconfig | 2 +-
> arch/arm/mm/mmu.c | 26 -
> 49 files changed, 7 insertions(+), 6262 deletions(-)
> delete mode 100644 arch/arm/include/asm/kvm_arm.h
> delete mode 100644 arch/arm/include/asm/kvm_asm.h
> delete mode 100644 arch/arm/include/asm/kvm_coproc.h
> delete mode 100644 arch/arm/include/asm/kvm_emulate.h
> delete mode 100644 arch/arm/include/asm/kvm_host.h
> delete mode 100644 arch/arm/include/asm/kvm_hyp.h
> delete mode 100644 arch/arm/include/asm/kvm_mmu.h
> delete mode 100644 arch/arm/include/asm/kvm_ras.h
> delete mode 100644 arch/arm/include/asm/stage2_pgtable.h
> delete mode 100644 arch/arm/include/uapi/asm/kvm.h
> delete mode 100644 arch/arm/kvm/Kconfig
> delete mode 100644 arch/arm/kvm/Makefile
> delete mode 100644 arch/arm/kvm/coproc.c
> delete mode 100644 arch/arm/kvm/coproc.h
> delete mode 100644 arch/arm/kvm/coproc_a15.c
> delete mode 100644 arch/arm/kvm/coproc_a7.c
> delete mode 100644 arch/arm/kvm/emulate.c
> delete mode 100644 arch/arm/kvm/guest.c
> delete mode 100644 arch/arm/kvm/handle_exit.c
> delete mode 100644 arch/arm/kvm/hyp/Makefile
> delete mode 100644 arch/arm/kvm/hyp/banked-sr.c
> delete mode 100644 arch/arm/kvm/hyp/cp15-sr.c
> delete mode 100644 arch/arm/kvm/hyp/entry.S
> delete mode 100644 arch/arm/kvm/hyp/hyp-entry.S
> delete mode 100644 arch/arm/kvm/hyp/s2-setup.c
> delete mode 100644 arch/arm/kvm/hyp/switch.c
> delete mode 100644 arch/arm/kvm/hyp/tlb.c
> delete mode 100644 arch/arm/kvm/hyp/vfp.S
> delete mode 100644 arch/arm/kvm/init.S
> delete mode 100644 arch/arm/kvm/interrupts.S
> delete mode 100644 arch/arm/kvm/irq.h
> delete mode 100644 arch/arm/kvm/reset.c
> delete mode 100644 arch/arm/kvm/trace.h
> delete mode 100644 arch/arm/kvm/vgic-v3-coproc.c
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
2020-02-20 12:44 ` Marek Szyprowski
@ 2020-02-20 13:15 ` Marc Zyngier
2020-02-20 13:17 ` Paolo Bonzini
2020-02-20 13:32 ` Robin Murphy
0 siblings, 2 replies; 30+ messages in thread
From: Marc Zyngier @ 2020-02-20 13:15 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Russell King, kvm, Arnd Bergmann, Krzysztof Kozlowski,
Bartlomiej Zolnierkiewicz, Paolo Bonzini, Will Deacon, kvmarm,
linux-arm-kernel
Hi Marek,
On 2020-02-20 12:44, Marek Szyprowski wrote:
> Hi Marc,
>
> On 10.02.2020 15:13, 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:
>>
>> - It is incomplete (no debug support, no PMU)
>> - It hasn't followed any of the architectural evolutions
>> - It has zero users (I don't count myself here)
>> - It is more and more getting in the way of new arm64 developments
>
> That is a bit sad information. Mainline Exynos finally got everything
> that was needed to run it on the quite popular Samsung Exynos5422-based
> Odroid XU4/HC1/MC1 boards. According to the Odroid related forums it is
> being used. We also use it internally at Samsung.
Something like "too little, too late" springs to mind, but let's be
constructive. Is anyone using it in a production environment, where
they rely on the latest mainline kernel having KVM support?
The current proposal is to still have KVM support in 5.6, as well as
ongoing support for stable kernels. If that's not enough, can you please
explain your precise use case?
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
2020-02-20 13:15 ` Marc Zyngier
@ 2020-02-20 13:17 ` Paolo Bonzini
2020-02-20 13:32 ` Robin Murphy
1 sibling, 0 replies; 30+ messages in thread
From: Paolo Bonzini @ 2020-02-20 13:17 UTC (permalink / raw)
To: Marc Zyngier, Marek Szyprowski
Cc: Russell King, kvm, Arnd Bergmann, Krzysztof Kozlowski,
Bartlomiej Zolnierkiewicz, Will Deacon, kvmarm, linux-arm-kernel
On 20/02/20 14:15, Marc Zyngier wrote:
>> That is a bit sad information. Mainline Exynos finally got everything
>> that was needed to run it on the quite popular Samsung Exynos5422-based
>> Odroid XU4/HC1/MC1 boards. According to the Odroid related forums it is
>> being used. We also use it internally at Samsung.
>
> Something like "too little, too late" springs to mind, but let's be
> constructive. Is anyone using it in a production environment, where
> they rely on the latest mainline kernel having KVM support?
Depends if you consider "production environment" somebody playing at
home with a SBC. But it's true that, these days, most of those that
support EL2 do support ARM64, even if they are used with a 32-bit userland.
Paolo
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
2020-02-20 13:15 ` Marc Zyngier
2020-02-20 13:17 ` Paolo Bonzini
@ 2020-02-20 13:32 ` Robin Murphy
2020-02-20 14:01 ` Marc Zyngier
1 sibling, 1 reply; 30+ messages in thread
From: Robin Murphy @ 2020-02-20 13:32 UTC (permalink / raw)
To: Marc Zyngier, Marek Szyprowski
Cc: Russell King, kvm, Arnd Bergmann, Krzysztof Kozlowski,
Bartlomiej Zolnierkiewicz, linux-arm-kernel, Paolo Bonzini,
Will Deacon, kvmarm
On 20/02/2020 1:15 pm, Marc Zyngier wrote:
> Hi Marek,
>
> On 2020-02-20 12:44, Marek Szyprowski wrote:
>> Hi Marc,
>>
>> On 10.02.2020 15:13, 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:
>>>
>>> - It is incomplete (no debug support, no PMU)
>>> - It hasn't followed any of the architectural evolutions
>>> - It has zero users (I don't count myself here)
>>> - It is more and more getting in the way of new arm64 developments
>>
>> That is a bit sad information. Mainline Exynos finally got everything
>> that was needed to run it on the quite popular Samsung Exynos5422-based
>> Odroid XU4/HC1/MC1 boards. According to the Odroid related forums it is
>> being used. We also use it internally at Samsung.
>
> Something like "too little, too late" springs to mind, but let's be
> constructive. Is anyone using it in a production environment, where
> they rely on the latest mainline kernel having KVM support?
>
> The current proposal is to still have KVM support in 5.6, as well as
> ongoing support for stable kernels. If that's not enough, can you please
> explain your precise use case?
Presumably there's no *technical* reason why the stable subset of v7
support couldn't be stripped down and brought back private to arch/arm
if somebody really wants and is willing to step up and look after it?
Robin.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
2020-02-20 13:32 ` Robin Murphy
@ 2020-02-20 14:01 ` Marc Zyngier
2020-02-20 14:38 ` Robin Murphy
0 siblings, 1 reply; 30+ messages in thread
From: Marc Zyngier @ 2020-02-20 14:01 UTC (permalink / raw)
To: Robin Murphy
Cc: Russell King, kvm, Arnd Bergmann, Krzysztof Kozlowski,
Bartlomiej Zolnierkiewicz, linux-arm-kernel, Paolo Bonzini,
Will Deacon, kvmarm, Marek Szyprowski
On 2020-02-20 13:32, Robin Murphy wrote:
> On 20/02/2020 1:15 pm, Marc Zyngier wrote:
>> Hi Marek,
>>
>> On 2020-02-20 12:44, Marek Szyprowski wrote:
>>> Hi Marc,
>>>
>>> On 10.02.2020 15:13, 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:
>>>>
>>>> - It is incomplete (no debug support, no PMU)
>>>> - It hasn't followed any of the architectural evolutions
>>>> - It has zero users (I don't count myself here)
>>>> - It is more and more getting in the way of new arm64 developments
>>>
>>> That is a bit sad information. Mainline Exynos finally got everything
>>> that was needed to run it on the quite popular Samsung
>>> Exynos5422-based
>>> Odroid XU4/HC1/MC1 boards. According to the Odroid related forums it
>>> is
>>> being used. We also use it internally at Samsung.
>>
>> Something like "too little, too late" springs to mind, but let's be
>> constructive. Is anyone using it in a production environment, where
>> they rely on the latest mainline kernel having KVM support?
>>
>> The current proposal is to still have KVM support in 5.6, as well as
>> ongoing support for stable kernels. If that's not enough, can you
>> please
>> explain your precise use case?
>
> Presumably there's no *technical* reason why the stable subset of v7
> support couldn't be stripped down and brought back private to arch/arm
> if somebody really wants and is willing to step up and look after it?
There is no technical reason at all, just a maintenance effort.
The main killer is the whole MMU code, which I'm butchering with NV,
and that I suspect Will will also turn upside down with his stuff.
Not to mention the hypercall interface that will need a complete
overhaul.
If we wanted to decouple the two, we'd need to make the MMU code, the
hypercalls, arm.c and a number of other bits private to 32bit.
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
2020-02-20 14:01 ` Marc Zyngier
@ 2020-02-20 14:38 ` Robin Murphy
0 siblings, 0 replies; 30+ messages in thread
From: Robin Murphy @ 2020-02-20 14:38 UTC (permalink / raw)
To: Marc Zyngier
Cc: Russell King, kvm, Arnd Bergmann, Krzysztof Kozlowski,
Bartlomiej Zolnierkiewicz, linux-arm-kernel, Paolo Bonzini,
Will Deacon, kvmarm, Marek Szyprowski
On 20/02/2020 2:01 pm, Marc Zyngier wrote:
> On 2020-02-20 13:32, Robin Murphy wrote:
>> On 20/02/2020 1:15 pm, Marc Zyngier wrote:
>>> Hi Marek,
>>>
>>> On 2020-02-20 12:44, Marek Szyprowski wrote:
>>>> Hi Marc,
>>>>
>>>> On 10.02.2020 15:13, 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:
>>>>>
>>>>> - It is incomplete (no debug support, no PMU)
>>>>> - It hasn't followed any of the architectural evolutions
>>>>> - It has zero users (I don't count myself here)
>>>>> - It is more and more getting in the way of new arm64 developments
>>>>
>>>> That is a bit sad information. Mainline Exynos finally got everything
>>>> that was needed to run it on the quite popular Samsung Exynos5422-based
>>>> Odroid XU4/HC1/MC1 boards. According to the Odroid related forums it is
>>>> being used. We also use it internally at Samsung.
>>>
>>> Something like "too little, too late" springs to mind, but let's be
>>> constructive. Is anyone using it in a production environment, where
>>> they rely on the latest mainline kernel having KVM support?
>>>
>>> The current proposal is to still have KVM support in 5.6, as well as
>>> ongoing support for stable kernels. If that's not enough, can you please
>>> explain your precise use case?
>>
>> Presumably there's no *technical* reason why the stable subset of v7
>> support couldn't be stripped down and brought back private to arch/arm
>> if somebody really wants and is willing to step up and look after it?
>
> There is no technical reason at all, just a maintenance effort.
>
> The main killer is the whole MMU code, which I'm butchering with NV,
> and that I suspect Will will also turn upside down with his stuff.
> Not to mention the hypercall interface that will need a complete overhaul.
>
> If we wanted to decouple the two, we'd need to make the MMU code, the
> hypercalls, arm.c and a number of other bits private to 32bit.
Right, the prospective kvm-arm maintainer's gameplan would essentially
be an equivalent "move virt/kvm/arm to arch/arm/kvm" patch, but then
ripping out all the Armv8 and GICv3 gubbins instead. Yes, there would
then be lots of *similar* code to start with, but it would only diverge
further as v8 architecture development continues independently.
Anyway, I just thought it seemed worth saying out loud, to reassure
folks that a realistic middle-ground between "yay bye!" and "oh no the
end of the world!" does exist, namely "someone else's problem" :)
Robin.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
2020-02-10 14:13 ` [RFC PATCH 0/5] Removing support for 32bit KVM/arm host Marc Zyngier
` (14 preceding siblings ...)
2020-02-20 12:44 ` Marek Szyprowski
@ 2020-02-22 14:21 ` Takashi Yoshi
2020-02-22 14:40 ` Takashi Yoshi
16 siblings, 0 replies; 30+ messages in thread
From: Takashi Yoshi @ 2020-02-22 14:21 UTC (permalink / raw)
To: Marc Zyngier, linux-arm-kernel, kvmarm, kvm
Cc: Anders Berg, Russell King, Arnd Bergmann, Paolo Bonzini, Will Deacon
[-- Attachment #1: Type: text/plain, Size: 3285 bytes --]
Hi
I found this mailing list thread and would like to express my opinion
and dependence on KVM/arm32.
I hope that I'm not too late already.
On Monday, 10.02.2020, 14:13 +0000 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:
>
> - It is incomplete (no debug support, no PMU)
> - It hasn't followed any of the architectural evolutions
> - It has zero users (I don't count myself here)
I might not be an important user, but I have been for multiple years
and still am a regular user of KVM/arm32 on different devices.
I use KVM on my Tegra K1 Chromebook for app development and have
multiple SBCs at home on which I run VMs on using KVM+libvirt.
Sure, neither of these devices has many resources available, but they
are working fine. I would love to keep them in service since I haven't
found arm64-based replacements that don't require hours upon hours of
tinkering to just get a basic OS installation running with a mainline
kernel.
As an example that they can still be of use in 2020 I'd like to point
out that one of the SBCs is running my DNS resolver, LDAP server,
RSS reader, IRC bouncer, and shared todo list just fine, each in their
separate VM.
> - It is more and more getting in the way of new arm64 developments
>
> So here it is: unless someone screams and shows that they rely on
> KVM/arm to be maintained upsteam, I'll remove 32bit host support
> form the tree.
*scream*
> One of the reasons that makes me confident nobody is
> using it is that I never receive *any* bug report. Yes, it is
> perfect.
This assumption is deeply flawed. Most users (including me) are not
subscribed to this mailing list and will never find this thread at all.
I myself stumbled upon this discussion just by chance while I was
browsing the web trying to find something completely unrelated.
I've been using KVM on x86, ppc and arm for many years, yet I never
felt the need to report a bug on the mailing list.
(This is to be interpreted as a compliment to the great work the devs
of KVM have done!)
Just going by the number of bugs reported on a developers mailing list
is not going to paint an accurate picture.
I am convinced that I'm not the only one relying on KVM/arm32 in the
mainline kernel and would ask you to please reconsider keeping arm32 in
the mainline kernel for a few more years until adequate arm64
replacements are available on the market and have gained proper support
in the mainline kernel.
I myself unfortunately do neither have the knowledge nor resources to
help with development in KVM or maintaining a non-mainline kernel.
> But if you depend on KVM/arm being available in mainline, please
> shout.
>
> To reiterate: 32bit guest support for arm64 stays, of course. Only
> 32bit host goes. Once this is merged, I plan to move virt/kvm/arm to
> arm64, and cleanup all the now unnecessary abstractions.
>
> The patches have been generated with the -D option to avoid spamming
> everyone with huge diffs, and there is a kvm-arm/goodbye branch in
> my kernel.org repository.
>
> [...]
Thanks for your understanding.
Kind regards
- Yoshi
[-- Attachment #2: Original html part --]
[-- Type: text/html, Size: 14544 bytes --]
[-- Attachment #3: Type: text/plain, Size: 151 bytes --]
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
2020-02-10 14:13 ` [RFC PATCH 0/5] Removing support for 32bit KVM/arm host Marc Zyngier
` (15 preceding siblings ...)
2020-02-22 14:21 ` Takashi Yoshi
@ 2020-02-22 14:40 ` Takashi Yoshi
2020-02-22 21:31 ` Arnd Bergmann
16 siblings, 1 reply; 30+ messages in thread
From: Takashi Yoshi @ 2020-02-22 14:40 UTC (permalink / raw)
To: Marc Zyngier, linux-arm-kernel, kvmarm, kvm
Cc: Anders Berg, Russell King, Arnd Bergmann, Paolo Bonzini, Will Deacon
Hi
I found this mailing list thread and would like to express my opinion
and dependence on KVM/arm32.
I hope that I'm not too late already.
On Monday, 10.02.2020, 14:13 +0000 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:
>
> - It is incomplete (no debug support, no PMU)
> - It hasn't followed any of the architectural evolutions
> - It has zero users (I don't count myself here)
I might not be an important user, but I have been for multiple years
and still am a regular user of KVM/arm32 on different devices.
I use KVM on my Tegra K1 Chromebook for app development and have
multiple SBCs at home on which I run VMs on using KVM+libvirt.
Sure, neither of these devices has many resources available, but they
are working fine. I would love to keep them in service since I haven't
found arm64-based replacements that don't require hours upon hours of
tinkering to just get a basic OS installation running with a mainline
kernel.
As an example that they can still be of use in 2020 I'd like to point
out that one of the SBCs is running my DNS resolver, LDAP server,
RSS reader, IRC bouncer, and shared todo list just fine, each in their
separate VM.
> - It is more and more getting in the way of new arm64 developments
>
> So here it is: unless someone screams and shows that they rely on
> KVM/arm to be maintained upsteam, I'll remove 32bit host support
> form the tree.
*scream*
> One of the reasons that makes me confident nobody is
> using it is that I never receive *any* bug report. Yes, it is
> perfect.
This assumption is deeply flawed. Most users (including me) are not
subscribed to this mailing list and will never find this thread at all.
I myself stumbled upon this discussion just by chance while I was
browsing the web trying to find something completely unrelated.
I've been using KVM on x86, ppc and arm for many years, yet I never
felt the need to report a bug on the mailing list.
(This is to be interpreted as a compliment to the great work the devs
of KVM have done!)
Just going by the number of bugs reported on a developers mailing list
is not going to paint an accurate picture.
I am convinced that I'm not the only one relying on KVM/arm32 in the
mainline kernel and would ask you to please reconsider keeping arm32 in
the mainline kernel for a few more years until adequate arm64
replacements are available on the market and have gained proper support
in the mainline kernel.
I myself unfortunately do neither have the knowledge nor resources to
help with development in KVM or maintaining a non-mainline kernel.
> But if you depend on KVM/arm being available in mainline, please
> shout.
>
> To reiterate: 32bit guest support for arm64 stays, of course. Only
> 32bit host goes. Once this is merged, I plan to move virt/kvm/arm to
> arm64, and cleanup all the now unnecessary abstractions.
>
> The patches have been generated with the -D option to avoid spamming
> everyone with huge diffs, and there is a kvm-arm/goodbye branch in
> my kernel.org repository.
>
> [...]
Thanks for your understanding.
Kind regards
- Yoshi
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
2020-02-22 14:40 ` Takashi Yoshi
@ 2020-02-22 21:31 ` Arnd Bergmann
2020-02-25 21:34 ` Takashi Yoshi
0 siblings, 1 reply; 30+ messages in thread
From: Arnd Bergmann @ 2020-02-22 21:31 UTC (permalink / raw)
To: Takashi Yoshi
Cc: Anders Berg, Russell King, kvm list, Marc Zyngier, Paolo Bonzini,
Will Deacon, kvmarm, Linux ARM
On Sat, Feb 22, 2020 at 3:40 PM Takashi Yoshi <takashi@yoshi.email> wrote:
> On Monday, 10.02.2020, 14:13 +0000 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:
> >
> > - It is incomplete (no debug support, no PMU)
> > - It hasn't followed any of the architectural evolutions
> > - It has zero users (I don't count myself here)
>
> I might not be an important user, but I have been for multiple years
> and still am a regular user of KVM/arm32 on different devices.
>
> I use KVM on my Tegra K1 Chromebook for app development and have
> multiple SBCs at home on which I run VMs on using KVM+libvirt.
>
> Sure, neither of these devices has many resources available, but they
> are working fine. I would love to keep them in service since I haven't
> found arm64-based replacements that don't require hours upon hours of
> tinkering to just get a basic OS installation running with a mainline
> kernel.
>
> As an example that they can still be of use in 2020 I'd like to point
> out that one of the SBCs is running my DNS resolver, LDAP server,
> RSS reader, IRC bouncer, and shared todo list just fine, each in their
> separate VM.
Thank you for providing an important data point to this question.
> > - It is more and more getting in the way of new arm64 developments
> >
> > So here it is: unless someone screams and shows that they rely on
> > KVM/arm to be maintained upsteam, I'll remove 32bit host support
> > form the tree.
>
> *scream*
>
> > One of the reasons that makes me confident nobody is
> > using it is that I never receive *any* bug report. Yes, it is
> > perfect.
>
> This assumption is deeply flawed. Most users (including me) are not
> subscribed to this mailing list and will never find this thread at all.
> I myself stumbled upon this discussion just by chance while I was
> browsing the web trying to find something completely unrelated.
>
> I've been using KVM on x86, ppc and arm for many years, yet I never
> felt the need to report a bug on the mailing list.
> (This is to be interpreted as a compliment to the great work the devs
> of KVM have done!)
>
> Just going by the number of bugs reported on a developers mailing list
> is not going to paint an accurate picture.
>
> I am convinced that I'm not the only one relying on KVM/arm32 in the
> mainline kernel and would ask you to please reconsider keeping arm32 in
> the mainline kernel for a few more years until adequate arm64
> replacements are available on the market and have gained proper support
> in the mainline kernel.
Can you provide some more information about how you use KVM on 32-bit
machines, to make it possible to better estimate how many others might
do the same, and how long you will need to upgrade to newer kernels for?
In particular:
- What is the smallest amount of physical RAM that you have to found to
make a usable ARM/KVM host? Note that the 4GB configuration of the
Tegra K1 (an rk3288) Chromebooks seems to be extremely rare in other
devices, while most new 32-bit SBCs come with 1GB or less these days.
- How often do you update the host kernels on those 32-bit machines that
you still use to newer releases? What is the oldest/newest you run at the
moment?
- Are you able to move the host installation to a distribution with a long-term
stable release cycle such as Debian, Ubuntu that gives you a ~five year
support after a kernel release?
Arnd
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
2020-02-22 21:31 ` Arnd Bergmann
@ 2020-02-25 21:34 ` Takashi Yoshi
0 siblings, 0 replies; 30+ messages in thread
From: Takashi Yoshi @ 2020-02-25 21:34 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Anders Berg, Russell King, kvm list, Marc Zyngier, Paolo Bonzini,
Will Deacon, kvmarm, Linux ARM
Dear Arnd
Please excuse my late response.
On Sat, 22 Feb 2020 22:31:40 +0100 Arnd Bergmann <arnd@arndb.de> wrote:
> On Sat, Feb 22, 2020 at 3:40 PM Takashi Yoshi <takashi@yoshi.email>
> wrote:
> > On Monday, 10.02.2020, 14:13 +0000 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:
> > >
> > > - It is incomplete (no debug support, no PMU)
> > > - It hasn't followed any of the architectural evolutions
> > > - It has zero users (I don't count myself here)
> >
> > I might not be an important user, but I have been for multiple years
> > and still am a regular user of KVM/arm32 on different devices.
> >
> > I use KVM on my Tegra K1 Chromebook for app development and have
> > multiple SBCs at home on which I run VMs on using KVM+libvirt.
> >
> > Sure, neither of these devices has many resources available, but
> > they are working fine. I would love to keep them in service since I
> > haven't found arm64-based replacements that don't require hours
> > upon hours of tinkering to just get a basic OS installation running
> > with a mainline kernel.
> >
> > As an example that they can still be of use in 2020 I'd like to
> > point out that one of the SBCs is running my DNS resolver, LDAP
> > server, RSS reader, IRC bouncer, and shared todo list just fine,
> > each in their separate VM.
>
> Thank you for providing an important data point to this question.
>
> > > - It is more and more getting in the way of new arm64 developments
> > >
> > > So here it is: unless someone screams and shows that they rely on
> > > KVM/arm to be maintained upsteam, I'll remove 32bit host support
> > > form the tree.
> >
> > *scream*
> >
> > > One of the reasons that makes me confident nobody is
> > > using it is that I never receive *any* bug report. Yes, it is
> > > perfect.
> >
> > This assumption is deeply flawed. Most users (including me) are not
> > subscribed to this mailing list and will never find this thread at
> > all. I myself stumbled upon this discussion just by chance while I
> > was browsing the web trying to find something completely unrelated.
> >
> > I've been using KVM on x86, ppc and arm for many years, yet I never
> > felt the need to report a bug on the mailing list.
> > (This is to be interpreted as a compliment to the great work the
> > devs of KVM have done!)
> >
> > Just going by the number of bugs reported on a developers mailing
> > list is not going to paint an accurate picture.
> >
> > I am convinced that I'm not the only one relying on KVM/arm32 in the
> > mainline kernel and would ask you to please reconsider keeping
> > arm32 in the mainline kernel for a few more years until adequate
> > arm64 replacements are available on the market and have gained
> > proper support in the mainline kernel.
>
> Can you provide some more information about how you use KVM on 32-bit
> machines, to make it possible to better estimate how many others might
> do the same,
Sure.
First of all I own different ARM boards. Currently I virtualise on
Banana Pi M1 (1GB), cubox-i (2GB) and my Acer Chromebook (4GB).
The Chromebook is my travel laptop on which I have three VMs on (LAMP,
PostgreSQL, kernel testing) which I primarily use to develop against.
The others are "home servers", they run all kinds of things for my home
(incl. DNS, LDAP, RSS-Reader, Wiki, Music-Database, RDBMS,
Task-Management).
> and how long you will need to upgrade to newer kernels for?
I don't really have a strict policy regarding when to upgrade kernels.
I just run whatever gets patched and works.
Sometimes this is the latest stable release, most of the time this is
the last longterm release.
> In particular:
>
> - What is the smallest amount of physical RAM that you have to found
> to make a usable ARM/KVM host?
Not sure if I can answer this question adequately as the smallest of my
ARM32 boards have at least 1GB of RAM, which works for sure.
Since you're asking about the smallest amount I did some experiments.
I spun up the testing VM on my Chromebook. It consists of a basic
Gentoo userland currently running on a "reduced" 4.19 kernel (I'm sure
it could be stripped further if one was determined enough).
When I boot it up and log in the qemu-system process on the host uses
100MB. The memory usage (incl. cache) inside the VM is only 50 MB,
though.
Adding a few MB for the actual application one would want to run to
these 100MB, I calculate with 160MB for a "lightweight" VM.
This would mean that one could run 2-3 such VMs in just 512MB which I
would count as "usable".
If you were conservative with memory and used a lightweight distro, like
Alpine, OpenWrt or built your own using Buildroot, I could imagine that
you can make a nice little home router with virtualized DHCP server,
DNS server (for home network) + resolver, TFTP and possibly VPN in
512MB.
(Sounds like a cool experiment for the next time im bored :P)
A very different use case could be to host unikernels using e.g.
Solo5 (https://github.com/Solo5/solo5) whose hvt backend also uses KVM.
I, unfortunately, don't have any experience with unikernels, but I
assume that they consume a lot less memory than a full Linux VM.
> Note that the 4GB configuration of the Tegra K1 (an rk3288)
> Chromebooks seems to be extremely rare in other devices, while most
> new 32-bit SBCs come with 1GB or less these days.
I agree that 4GB seems to be really rare in 32-bit land outside of
laptops like Chromebooks or Novena, but I don't agree that most 32-bit
SBCs are so low specced.
There are quite a few 2GB boards out there:
ODROID U2/U3/X2/XU/XU3/XU4/HC1/HC2, Cubieboard 3/4/5, HummingBoard,
CuBox i4/Pulse, ASUS TinkerBoard (S), Lenovo G66 TV-Box, Radxa ROCK PRO
/ Rock2, Nvidia Jetson TK1, Banana Pi M2U/M3, Firefly RK3288,
BeagleBoard X15, OrangePi Plus 2E, Utilite, Wandboard, ClearFog,
NetGate SC3100, and probably a lot more can be had with 2GB RAM.
(If I were to buy an SBC for virtualization, I'd get one of these :-))
Also lets not forget all the powerful smartphones out there which could
be used as virtualizers using postmarketos.org.
> - How often do you update the host kernels on those 32-bit machines
> that you still use to newer releases?
I usually track the latest longterm branch (but I wait a bit before
jumping to a new longterm). So at the moment the majority is running
4.19.x, but I'm in the process of upgrading to 5.4.x now that most of
the annoying bugs should be fixed ;-)
> What is the oldest/newest you run at the moment?
Oldest: 4.15.18 (because of an annoying regression that's likely never
going to get fixed)
Newest: 5.4.20
> - Are you able to move the host installation to a distribution with a
> long-term stable release cycle such as Debian, Ubuntu that gives you
> a ~five year support after a kernel release?
I could do that, but I would like to avoid being dependent on an old
kernel as from personal experience even on so-called "longterm"
releases regressions do slip in and tend not to get fixed if they're
not too severe, especially in old distro kernels.
Kind regards,
- Yoshi
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply [flat|nested] 30+ messages in thread