Re: [PATCH v2 0/2] KVM/arm64: sys_reg_table_init() small improvements
On Thu, 28 Apr 2022 11:34:03 +0100, Alexandru Elisei wrote: > These are two small improvements to how KVM handles an out-of-order > sys_reg_desc table. These should only affect KVM developers, as the end > user should never see an error caused by an unsorted sys_reg_desc table. > > Changes in v2: > > * Tweaked how the error is detected and propagated in kvm_arch_init(). > * Use %pS to print the table name and entry offset (Marc). > * Tweaked the error message to spell out that magic number refers to the > offending entry. > > [...] Applied to next, thanks! [1/2] KVM/arm64: Don't BUG_ON() if emulated register table is unsorted commit: f1f0c0cfeaa7c10eb536d9919bf3902af0e17bce [2/2] KVM/arm64: Print emulated register table name when it is unsorted commit: 325031d4f39cfb1adf41708c1329e60b9abfbdac Cheers, M. -- Without deviation from the norm, progress is not possible. ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v2 2/5] KVM: arm64: Compile stacktrace.nvhe.o
On Mon, May 02, 2022 at 12:12:02PM -0700, Kalesh Singh wrote:
> Recompile stack unwinding code for use with the nVHE hypervisor. This is
> a preparatory patch that will allow reusing most of the kernel unwinding
> logic in the nVHE hypervisor.
> enum stack_type {
> - STACK_TYPE_UNKNOWN,
> +#ifndef __KVM_NVHE_HYPERVISOR__
> STACK_TYPE_TASK,
> STACK_TYPE_IRQ,
> STACK_TYPE_OVERFLOW,
> STACK_TYPE_SDEI_NORMAL,
> STACK_TYPE_SDEI_CRITICAL,
> +#endif /* !__KVM_NVHE_HYPERVISOR__ */
> + STACK_TYPE_UNKNOWN,
> __NR_STACK_TYPES
> };
I don't immediately see a problem with it but I'm curious as to why
STACK_TYPE_UNKNOWN got moved to the end of the list here? It does mean
that zeroed memory will default to STACK_TYPE_TASK but we're not
actually relying on that. Otherwise
Reviwed-by: Mark Brown
signature.asc
Description: PGP signature
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v2 1/5] KVM: arm64: Factor out common stack unwinding logic
On Mon, May 02, 2022 at 12:12:01PM -0700, Kalesh Singh wrote: > Factor out the stack unwinding logic common to both the host kernel and > the nVHE hypersivor into __unwind_next(). This allows for reuse in the > nVHE hypervisor stack unwinding (later in this series). Reviewed-by: Mark Brown signature.asc Description: PGP signature ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v6 00/12] KVM: arm64: PSCI SYSTEM_SUSPEND support
On Wed, 4 May 2022 03:24:34 +, Oliver Upton wrote: > The PSCI v1.0 specification describes a call, SYSTEM_SUSPEND, which > allows software to request that the system be placed into the lowest > possible power state and await a wakeup event. This call is optional > in v1.0 and v1.1. KVM does not currently support this optional call. > > This series adds support for the PSCI SYSTEM_SUSPEND call to KVM/arm64. > For reasons best described in patch 8, it is infeasible to correctly > implement PSCI SYSTEM_SUSPEND (or any system-wide event for that matter) > in a split design between kernel/userspace. As such, this series cheaply > exits to userspace so it can decide what to do with the call. This > series also gives userspace some help to emulate suspension with a new > MP state that awaits an unmasked pending interrupt. > > [...] Applied to next, thanks! [01/12] KVM: arm64: Don't depend on fallthrough to hide SYSTEM_RESET2 commit: 5bc2cb95ad03d866422d7b3f19ec42a6720f3262 [02/12] KVM: arm64: Dedupe vCPU power off helpers commit: 1e5794295c5dbfcc31cf5de840c9e095ae50efb7 [03/12] KVM: arm64: Track vCPU power state using MP state values commit: b171f9bbb130cb323f2101edd32da2a25d43ebfa [04/12] KVM: arm64: Rename the KVM_REQ_SLEEP handler commit: 1c6219e3faf12e58d520b3b2cdfa8cd5e1efc9a5 [05/12] KVM: arm64: Return a value from check_vcpu_requests() commit: 3fdd04592d38bb31a0bea567d9a66672b484bed3 [06/12] KVM: arm64: Add support for userspace to suspend a vCPU commit: 7b33a09d036ffd9a04506122840629c7e870cf08 [07/12] KVM: arm64: Implement PSCI SYSTEM_SUSPEND commit: bfbab44568779e1682bc6f63688bb9c965f0e74a [08/12] selftests: KVM: Rename psci_cpu_on_test to psci_test commit: bf08515d39cb843c81f991ee67ff543eecdba0c3 [09/12] selftests: KVM: Create helper for making SMCCC calls commit: e918e2bc52c8ac1cccd6ef822ac23eded41761b6 [10/12] selftests: KVM: Use KVM_SET_MP_STATE to power off vCPU in psci_test commit: d135399a97cc3e27716a8e468a5fd1a209346831 [11/12] selftests: KVM: Refactor psci_test to make it amenable to new tests commit: 67a36a821312e9c0d2a2f7e6c2225204500cc01c [12/12] selftests: KVM: Test SYSTEM_SUSPEND PSCI call commit: b26dafc8a9e74254a390e8f21ff028a2573ee4fc Cheers, M. -- Without deviation from the norm, progress is not possible. ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v7 0/9] KVM: arm64: Add support for hypercall services selection
On Mon, 2 May 2022 23:38:44 +, Raghavendra Rao Ananta wrote: > Continuing the discussion from [1], the series tries to add support > for the userspace to elect the hypercall services that it wishes > to expose to the guest, rather than the guest discovering them > unconditionally. The idea employed by the series was taken from > [1] as suggested by Marc Z. > > In a broad sense, the concept is similar to the current implementation > of PSCI interface- create a 'firmware psuedo-register' to handle the > firmware revisions. The series extends this idea to all the other > hypercalls such as TRNG (True Random Number Generator), PV_TIME > (Paravirtualized Time), and PTP (Precision Time protocol). > > [...] Applied to next, thanks! [1/9] KVM: arm64: Factor out firmware register handling from psci.c commit: 85fbe08e4da862dc64fc10071c4a03e51b6361d0 [2/9] KVM: arm64: Setup a framework for hypercall bitmap firmware registers commit: 05714cab7d63b189894235cf310fae7d6ffc2e9b [3/9] KVM: arm64: Add standard hypervisor firmware register commit: 428fd6788d4d0e0d390de9fb4486be3c1187310d [4/9] KVM: arm64: Add vendor hypervisor firmware register commit: b22216e1a617ca55b41337cd1e057ebc784a65d4 [5/9] Docs: KVM: Rename psci.rst to hypercalls.rst commit: f1ced23a9be5727c6f4cac0e2262c5411038952f [6/9] Docs: KVM: Add doc for the bitmap firmware registers commit: fa246c68a04d46c7af6953b47dba7e16d24efbe2 [7/9] tools: Import ARM SMCCC definitions commit: ea733263949646700977feeb662a92703f514351 [8/9] selftests: KVM: aarch64: Introduce hypercall ABI test commit: 5ca24697d54027c1c94c94a5b920a75448108ed0 [9/9] selftests: KVM: aarch64: Add the bitmap firmware registers to get-reg-list commit: 920f4a55fdaa6f68b31c50cca6e51fecac5857a0 Cheers, M. -- Without deviation from the norm, progress is not possible. ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
[PATCH kernel] KVM: PPC: Make KVM_CAP_IRQFD_RESAMPLE platform dependent
When introduced, IRQFD resampling worked on POWER8 with XICS. However
KVM on POWER9 has never implemented it - the compatibility mode code
("XICS-on-XIVE") misses the kvm_notify_acked_irq() call and the native
XIVE mode does not handle INTx in KVM at all.
This moved the capability support advertising to platforms and stops
advertising it on XIVE, i.e. POWER9 and later.
Signed-off-by: Alexey Kardashevskiy
---
Or I could move this one together with KVM_CAP_IRQFD. Thoughts?
---
arch/arm64/kvm/arm.c | 3 +++
arch/mips/kvm/mips.c | 3 +++
arch/powerpc/kvm/powerpc.c | 6 ++
arch/riscv/kvm/vm.c| 3 +++
arch/s390/kvm/kvm-s390.c | 3 +++
arch/x86/kvm/x86.c | 3 +++
virt/kvm/kvm_main.c| 1 -
7 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 523bc934fe2f..092f0614bae3 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -210,6 +210,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
case KVM_CAP_SET_GUEST_DEBUG:
case KVM_CAP_VCPU_ATTRIBUTES:
case KVM_CAP_PTP_KVM:
+#ifdef CONFIG_HAVE_KVM_IRQFD
+ case KVM_CAP_IRQFD_RESAMPLE:
+#endif
r = 1;
break;
case KVM_CAP_SET_GUEST_DEBUG2:
diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
index a25e0b73ee70..0f3de470a73e 100644
--- a/arch/mips/kvm/mips.c
+++ b/arch/mips/kvm/mips.c
@@ -1071,6 +1071,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long
ext)
case KVM_CAP_READONLY_MEM:
case KVM_CAP_SYNC_MMU:
case KVM_CAP_IMMEDIATE_EXIT:
+#ifdef CONFIG_HAVE_KVM_IRQFD
+ case KVM_CAP_IRQFD_RESAMPLE:
+#endif
r = 1;
break;
case KVM_CAP_NR_VCPUS:
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 875c30c12db0..87698ffef3be 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -591,6 +591,12 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
break;
#endif
+#ifdef CONFIG_HAVE_KVM_IRQFD
+ case KVM_CAP_IRQFD_RESAMPLE:
+ r = !xive_enabled();
+ break;
+#endif
+
case KVM_CAP_PPC_ALLOC_HTAB:
r = hv_enabled;
break;
diff --git a/arch/riscv/kvm/vm.c b/arch/riscv/kvm/vm.c
index c768f75279ef..b58579b386bb 100644
--- a/arch/riscv/kvm/vm.c
+++ b/arch/riscv/kvm/vm.c
@@ -63,6 +63,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
case KVM_CAP_READONLY_MEM:
case KVM_CAP_MP_STATE:
case KVM_CAP_IMMEDIATE_EXIT:
+#ifdef CONFIG_HAVE_KVM_IRQFD
+ case KVM_CAP_IRQFD_RESAMPLE:
+#endif
r = 1;
break;
case KVM_CAP_NR_VCPUS:
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index 156d1c25a3c1..85e093fc8d13 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -564,6 +564,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
case KVM_CAP_SET_GUEST_DEBUG:
case KVM_CAP_S390_DIAG318:
case KVM_CAP_S390_MEM_OP_EXTENSION:
+#ifdef CONFIG_HAVE_KVM_IRQFD
+ case KVM_CAP_IRQFD_RESAMPLE:
+#endif
r = 1;
break;
case KVM_CAP_SET_GUEST_DEBUG2:
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 0c0ca599a353..a0a7b769483d 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4273,6 +4273,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long
ext)
case KVM_CAP_SYS_ATTRIBUTES:
case KVM_CAP_VAPIC:
case KVM_CAP_ENABLE_CAP:
+#ifdef CONFIG_HAVE_KVM_IRQFD
+ case KVM_CAP_IRQFD_RESAMPLE:
+#endif
r = 1;
break;
case KVM_CAP_EXIT_HYPERCALL:
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 70e05af5ebea..885e72e668a5 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -4293,7 +4293,6 @@ static long kvm_vm_ioctl_check_extension_generic(struct
kvm *kvm, long arg)
#endif
#ifdef CONFIG_HAVE_KVM_IRQFD
case KVM_CAP_IRQFD:
- case KVM_CAP_IRQFD_RESAMPLE:
#endif
case KVM_CAP_IOEVENTFD_ANY_LENGTH:
case KVM_CAP_CHECK_EXTENSION_VM:
--
2.30.2
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v14 00/39] arm64/sme: Initial support for the Scalable Matrix Extension
On Wed, 4 May 2022 at 05:22, Mark Brown wrote: > > On Tue, May 03, 2022 at 06:23:40PM -0400, Qian Cai wrote: > > On Tue, Apr 19, 2022 at 12:22:08PM +0100, Mark Brown wrote: > > > This series provides initial support for the ARMv9 Scalable Matrix > > > Extension (SME). SME takes the approach used for vectors in SVE and > > > extends this to provide architectural support for matrix operations. A > > > more detailed overview can be found in [1]. > > > > Set CONFIG_ARM64_SME=n fixed a warning while running libhugetlbfs tests. I agree with this. The reported kernel warning gone with CONFIG_ARM64_SME=n - Naresh ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v14 00/39] arm64/sme: Initial support for the Scalable Matrix Extension
On Tue, Apr 19, 2022 at 12:22:08PM +0100, Mark Brown wrote:
> This series provides initial support for the ARMv9 Scalable Matrix
> Extension (SME). SME takes the approach used for vectors in SVE and
> extends this to provide architectural support for matrix operations. A
> more detailed overview can be found in [1].
Set CONFIG_ARM64_SME=n fixed a warning while running libhugetlbfs tests.
/*
* There are several places where we assume that the order value is sane
* so bail out early if the request is out of bound.
*/
if (unlikely(order >= MAX_ORDER)) {
WARN_ON_ONCE(!(gfp & __GFP_NOWARN));
return NULL;
}
WARNING: CPU: 122 PID: 4025 at mm/page_alloc.c:5383 __alloc_pages
CPU: 122 PID: 4025 Comm: brk_near_huge Not tainted 5.18.0-rc5-next-20220503 #79
pstate: 2049 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __alloc_pages
lr : alloc_pages
sp : 8000505470f0
x29: 8000505470f0 x28: 40028b3535c0 x27:
x26: 1a0a8ea2 x25: 800050547510 x24: 0dc0
x23: 921ddb818000 x22: 000e x21: 1a0a8e28
x20: 00040dc0 x19: ae1848c61ae0 x18: ae18357e7d24
x17: ae182fb75778 x16: 1fffe8005166a7d8 x15: 001a
x14: 1fffe8005166a7cb x13: 0004 x12: 7a0a8e03
x11: 1a0a8e02 x10: f204f1f1 x9 : f204
x8 : dfff8000 x7 : f300 x6 : f3f3f3f3
x5 : 7a0a8e28 x4 : 40028b3535c0 x3 :
x2 : 0001 x1 : 0001 x0 : 00040dc0
Call trace:
__alloc_pages
alloc_pages
kmalloc_order
kmalloc_order_trace
__kmalloc
__regset_get
regset_get_alloc
fill_thread_core_info
fill_note_info
elf_core_dump
do_coredump
get_signal
do_signal
do_notify_resume
el0_svc
el0t_64_sync_handler
el0t_64_sync
irq event stamp: 28066
hardirqs last enabled at (28065): _raw_spin_unlock_irqrestore
hardirqs last disabled at (28066): el1_dbg
softirqs last enabled at (27438): fpsimd_preserve_current_state
softirqs last disabled at (27436): fpsimd_preserve_current_state
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
