* [PATCH 2/2] kvm: rename KVM_MAX_VCPU_ID to KVM_MAX_VCPU_IDS
@ 2021-09-13 13:57 ` Juergen Gross
0 siblings, 0 replies; 27+ messages in thread
From: Juergen Gross @ 2021-09-13 13:57 UTC (permalink / raw)
To: kvm, x86, linux-doc, linux-kernel, linux-mips, kvm-ppc,
linuxppc-dev, linux-kselftest
Cc: Wanpeng Li, Paul Mackerras, H. Peter Anvin, Shuah Khan,
Jonathan Corbet, Joerg Roedel, Huacai Chen, Aleksandar Markovic,
Ingo Molnar, Eduardo Habkost, Borislav Petkov, Shuah Khan,
Thomas Gleixner, Jim Mattson, Juergen Gross, Thomas Bogendoerfer,
Sean Christopherson, Paolo Bonzini, Vitaly Kuznetsov
KVM_MAX_VCPU_ID is not specifying the highest allowed vcpu-id, but the
number of allowed vcpu-ids. This has already led to confusion, so
rename KVM_MAX_VCPU_ID to KVM_MAX_VCPU_IDS to make its semantics more
clear
Suggested-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
---
Documentation/virt/kvm/devices/xics.rst | 2 +-
Documentation/virt/kvm/devices/xive.rst | 2 +-
arch/mips/kvm/mips.c | 2 +-
arch/powerpc/include/asm/kvm_book3s.h | 2 +-
arch/powerpc/include/asm/kvm_host.h | 4 ++--
arch/powerpc/kvm/book3s_xive.c | 2 +-
arch/powerpc/kvm/powerpc.c | 2 +-
arch/x86/include/asm/kvm_host.h | 2 +-
arch/x86/kvm/ioapic.c | 2 +-
arch/x86/kvm/ioapic.h | 4 ++--
arch/x86/kvm/x86.c | 2 +-
include/linux/kvm_host.h | 4 ++--
tools/testing/selftests/kvm/kvm_create_max_vcpus.c | 2 +-
virt/kvm/kvm_main.c | 2 +-
14 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/Documentation/virt/kvm/devices/xics.rst b/Documentation/virt/kvm/devices/xics.rst
index 2d6927e0b776..bf32c77174ab 100644
--- a/Documentation/virt/kvm/devices/xics.rst
+++ b/Documentation/virt/kvm/devices/xics.rst
@@ -22,7 +22,7 @@ Groups:
Errors:
======= ==========================================
- -EINVAL Value greater than KVM_MAX_VCPU_ID.
+ -EINVAL Value greater than KVM_MAX_VCPU_IDS.
-EFAULT Invalid user pointer for attr->addr.
-EBUSY A vcpu is already connected to the device.
======= ==========================================
diff --git a/Documentation/virt/kvm/devices/xive.rst b/Documentation/virt/kvm/devices/xive.rst
index 8bdf3dc38f01..8b5e7b40bdf8 100644
--- a/Documentation/virt/kvm/devices/xive.rst
+++ b/Documentation/virt/kvm/devices/xive.rst
@@ -91,7 +91,7 @@ the legacy interrupt mode, referred as XICS (POWER7/8).
Errors:
======= ==========================================
- -EINVAL Value greater than KVM_MAX_VCPU_ID.
+ -EINVAL Value greater than KVM_MAX_VCPU_IDS.
-EFAULT Invalid user pointer for attr->addr.
-EBUSY A vCPU is already connected to the device.
======= ==========================================
diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
index 75c6f264c626..562aa878b266 100644
--- a/arch/mips/kvm/mips.c
+++ b/arch/mips/kvm/mips.c
@@ -1073,7 +1073,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
r = KVM_MAX_VCPUS;
break;
case KVM_CAP_MAX_VCPU_ID:
- r = KVM_MAX_VCPU_ID;
+ r = KVM_MAX_VCPU_IDS;
break;
case KVM_CAP_MIPS_FPU:
/* We don't handle systems with inconsistent cpu_has_fpu */
diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
index caaa0f592d8e..3d31f2c59e43 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -434,7 +434,7 @@ extern int kvmppc_h_logical_ci_store(struct kvm_vcpu *vcpu);
#define SPLIT_HACK_OFFS 0xfb000000
/*
- * This packs a VCPU ID from the [0..KVM_MAX_VCPU_ID) space down to the
+ * This packs a VCPU ID from the [0..KVM_MAX_VCPU_IDS) space down to the
* [0..KVM_MAX_VCPUS) space, using knowledge of the guest's core stride
* (but not its actual threading mode, which is not available) to avoid
* collisions.
diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index 080a7feb7731..59cb38b04ede 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -33,11 +33,11 @@
#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
#include <asm/kvm_book3s_asm.h> /* for MAX_SMT_THREADS */
-#define KVM_MAX_VCPU_ID (MAX_SMT_THREADS * KVM_MAX_VCORES)
+#define KVM_MAX_VCPU_IDS (MAX_SMT_THREADS * KVM_MAX_VCORES)
#define KVM_MAX_NESTED_GUESTS KVMPPC_NR_LPIDS
#else
-#define KVM_MAX_VCPU_ID KVM_MAX_VCPUS
+#define KVM_MAX_VCPU_IDS KVM_MAX_VCPUS
#endif /* CONFIG_KVM_BOOK3S_HV_POSSIBLE */
#define __KVM_HAVE_ARCH_INTC_INITIALIZED
diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c
index a18db9e16ea4..225008882958 100644
--- a/arch/powerpc/kvm/book3s_xive.c
+++ b/arch/powerpc/kvm/book3s_xive.c
@@ -1928,7 +1928,7 @@ int kvmppc_xive_set_nr_servers(struct kvmppc_xive *xive, u64 addr)
pr_devel("%s nr_servers=%u\n", __func__, nr_servers);
- if (!nr_servers || nr_servers > KVM_MAX_VCPU_ID)
+ if (!nr_servers || nr_servers > KVM_MAX_VCPU_IDS)
return -EINVAL;
mutex_lock(&xive->lock);
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index b4e6f70b97b9..8ab90ce8738f 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -649,7 +649,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
r = KVM_MAX_VCPUS;
break;
case KVM_CAP_MAX_VCPU_ID:
- r = KVM_MAX_VCPU_ID;
+ r = KVM_MAX_VCPU_IDS;
break;
#ifdef CONFIG_PPC_BOOK3S_64
case KVM_CAP_PPC_GET_SMMU_INFO:
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index f8f48a7ec577..261b7d857fc0 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -50,7 +50,7 @@
* so ratio of 4 should be enough.
*/
#define KVM_VCPU_ID_RATIO 4
-#define KVM_MAX_VCPU_ID (KVM_MAX_VCPUS * KVM_VCPU_ID_RATIO)
+#define KVM_MAX_VCPU_IDS (KVM_MAX_VCPUS * KVM_VCPU_ID_RATIO)
/* memory slots that are not exposed to userspace */
#define KVM_PRIVATE_MEM_SLOTS 3
diff --git a/arch/x86/kvm/ioapic.c b/arch/x86/kvm/ioapic.c
index 698969e18fe3..3358123be946 100644
--- a/arch/x86/kvm/ioapic.c
+++ b/arch/x86/kvm/ioapic.c
@@ -96,7 +96,7 @@ static unsigned long ioapic_read_indirect(struct kvm_ioapic *ioapic,
static void rtc_irq_eoi_tracking_reset(struct kvm_ioapic *ioapic)
{
ioapic->rtc_status.pending_eoi = 0;
- bitmap_zero(ioapic->rtc_status.dest_map.map, KVM_MAX_VCPU_ID);
+ bitmap_zero(ioapic->rtc_status.dest_map.map, KVM_MAX_VCPU_IDS);
}
static void kvm_rtc_eoi_tracking_restore_all(struct kvm_ioapic *ioapic);
diff --git a/arch/x86/kvm/ioapic.h b/arch/x86/kvm/ioapic.h
index 27e61ff3ac3e..e66e620c3bed 100644
--- a/arch/x86/kvm/ioapic.h
+++ b/arch/x86/kvm/ioapic.h
@@ -39,13 +39,13 @@ struct kvm_vcpu;
struct dest_map {
/* vcpu bitmap where IRQ has been sent */
- DECLARE_BITMAP(map, KVM_MAX_VCPU_ID);
+ DECLARE_BITMAP(map, KVM_MAX_VCPU_IDS);
/*
* Vector sent to a given vcpu, only valid when
* the vcpu's bit in map is set
*/
- u8 vectors[KVM_MAX_VCPU_ID];
+ u8 vectors[KVM_MAX_VCPU_IDS];
};
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 28ef14155726..fec43997522b 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4070,7 +4070,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
r = KVM_MAX_VCPUS;
break;
case KVM_CAP_MAX_VCPU_ID:
- r = KVM_MAX_VCPU_ID;
+ r = KVM_MAX_VCPU_IDS;
break;
case KVM_CAP_PV_MMU: /* obsolete */
r = 0;
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 041ca7f15ea4..d2b405170f6e 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -39,8 +39,8 @@
#include <asm/kvm_host.h>
#include <linux/kvm_dirty_ring.h>
-#ifndef KVM_MAX_VCPU_ID
-#define KVM_MAX_VCPU_ID KVM_MAX_VCPUS
+#ifndef KVM_MAX_VCPU_IDS
+#define KVM_MAX_VCPU_IDS KVM_MAX_VCPUS
#endif
/*
diff --git a/tools/testing/selftests/kvm/kvm_create_max_vcpus.c b/tools/testing/selftests/kvm/kvm_create_max_vcpus.c
index 0299cd81b8ba..f968dfd4ee88 100644
--- a/tools/testing/selftests/kvm/kvm_create_max_vcpus.c
+++ b/tools/testing/selftests/kvm/kvm_create_max_vcpus.c
@@ -53,7 +53,7 @@ int main(int argc, char *argv[])
kvm_max_vcpu_id = kvm_max_vcpus;
TEST_ASSERT(kvm_max_vcpu_id >= kvm_max_vcpus,
- "KVM_MAX_VCPU_ID (%d) must be at least as large as KVM_MAX_VCPUS (%d).",
+ "KVM_MAX_VCPU_IDS (%d) must be at least as large as KVM_MAX_VCPUS (%d).",
kvm_max_vcpu_id, kvm_max_vcpus);
test_vcpu_creation(0, kvm_max_vcpus);
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 439d3b4cd1a9..62fcbc897e1c 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -3557,7 +3557,7 @@ static int kvm_vm_ioctl_create_vcpu(struct kvm *kvm, u32 id)
struct kvm_vcpu *vcpu;
struct page *page;
- if (id >= KVM_MAX_VCPU_ID)
+ if (id >= KVM_MAX_VCPU_IDS)
return -EINVAL;
mutex_lock(&kvm->lock);
--
2.26.2
^ permalink raw reply related [flat|nested] 27+ messages in thread* [PATCH 2/2] kvm: rename KVM_MAX_VCPU_ID to KVM_MAX_VCPU_IDS
@ 2021-09-13 13:57 ` Juergen Gross
0 siblings, 0 replies; 27+ messages in thread
From: Juergen Gross @ 2021-09-13 13:57 UTC (permalink / raw)
To: kvm, x86, linux-doc, linux-kernel, linux-mips, kvm-ppc,
linuxppc-dev, linux-kselftest
Cc: Juergen Gross, Paolo Bonzini, Jonathan Corbet, Huacai Chen,
Aleksandar Markovic, Thomas Bogendoerfer, Paul Mackerras,
Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Sean Christopherson, Vitaly Kuznetsov, Wanpeng Li, Jim Mattson,
Joerg Roedel, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
H. Peter Anvin, Shuah Khan, Shuah Khan, Eduardo Habkost
KVM_MAX_VCPU_ID is not specifying the highest allowed vcpu-id, but the
number of allowed vcpu-ids. This has already led to confusion, so
rename KVM_MAX_VCPU_ID to KVM_MAX_VCPU_IDS to make its semantics more
clear
Suggested-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
---
Documentation/virt/kvm/devices/xics.rst | 2 +-
Documentation/virt/kvm/devices/xive.rst | 2 +-
arch/mips/kvm/mips.c | 2 +-
arch/powerpc/include/asm/kvm_book3s.h | 2 +-
arch/powerpc/include/asm/kvm_host.h | 4 ++--
arch/powerpc/kvm/book3s_xive.c | 2 +-
arch/powerpc/kvm/powerpc.c | 2 +-
arch/x86/include/asm/kvm_host.h | 2 +-
arch/x86/kvm/ioapic.c | 2 +-
arch/x86/kvm/ioapic.h | 4 ++--
arch/x86/kvm/x86.c | 2 +-
include/linux/kvm_host.h | 4 ++--
tools/testing/selftests/kvm/kvm_create_max_vcpus.c | 2 +-
virt/kvm/kvm_main.c | 2 +-
14 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/Documentation/virt/kvm/devices/xics.rst b/Documentation/virt/kvm/devices/xics.rst
index 2d6927e0b776..bf32c77174ab 100644
--- a/Documentation/virt/kvm/devices/xics.rst
+++ b/Documentation/virt/kvm/devices/xics.rst
@@ -22,7 +22,7 @@ Groups:
Errors:
======= ==========================================
- -EINVAL Value greater than KVM_MAX_VCPU_ID.
+ -EINVAL Value greater than KVM_MAX_VCPU_IDS.
-EFAULT Invalid user pointer for attr->addr.
-EBUSY A vcpu is already connected to the device.
======= ==========================================
diff --git a/Documentation/virt/kvm/devices/xive.rst b/Documentation/virt/kvm/devices/xive.rst
index 8bdf3dc38f01..8b5e7b40bdf8 100644
--- a/Documentation/virt/kvm/devices/xive.rst
+++ b/Documentation/virt/kvm/devices/xive.rst
@@ -91,7 +91,7 @@ the legacy interrupt mode, referred as XICS (POWER7/8).
Errors:
======= ==========================================
- -EINVAL Value greater than KVM_MAX_VCPU_ID.
+ -EINVAL Value greater than KVM_MAX_VCPU_IDS.
-EFAULT Invalid user pointer for attr->addr.
-EBUSY A vCPU is already connected to the device.
======= ==========================================
diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
index 75c6f264c626..562aa878b266 100644
--- a/arch/mips/kvm/mips.c
+++ b/arch/mips/kvm/mips.c
@@ -1073,7 +1073,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
r = KVM_MAX_VCPUS;
break;
case KVM_CAP_MAX_VCPU_ID:
- r = KVM_MAX_VCPU_ID;
+ r = KVM_MAX_VCPU_IDS;
break;
case KVM_CAP_MIPS_FPU:
/* We don't handle systems with inconsistent cpu_has_fpu */
diff --git a/arch/powerpc/include/asm/kvm_book3s.h b/arch/powerpc/include/asm/kvm_book3s.h
index caaa0f592d8e..3d31f2c59e43 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -434,7 +434,7 @@ extern int kvmppc_h_logical_ci_store(struct kvm_vcpu *vcpu);
#define SPLIT_HACK_OFFS 0xfb000000
/*
- * This packs a VCPU ID from the [0..KVM_MAX_VCPU_ID) space down to the
+ * This packs a VCPU ID from the [0..KVM_MAX_VCPU_IDS) space down to the
* [0..KVM_MAX_VCPUS) space, using knowledge of the guest's core stride
* (but not its actual threading mode, which is not available) to avoid
* collisions.
diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index 080a7feb7731..59cb38b04ede 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -33,11 +33,11 @@
#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
#include <asm/kvm_book3s_asm.h> /* for MAX_SMT_THREADS */
-#define KVM_MAX_VCPU_ID (MAX_SMT_THREADS * KVM_MAX_VCORES)
+#define KVM_MAX_VCPU_IDS (MAX_SMT_THREADS * KVM_MAX_VCORES)
#define KVM_MAX_NESTED_GUESTS KVMPPC_NR_LPIDS
#else
-#define KVM_MAX_VCPU_ID KVM_MAX_VCPUS
+#define KVM_MAX_VCPU_IDS KVM_MAX_VCPUS
#endif /* CONFIG_KVM_BOOK3S_HV_POSSIBLE */
#define __KVM_HAVE_ARCH_INTC_INITIALIZED
diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c
index a18db9e16ea4..225008882958 100644
--- a/arch/powerpc/kvm/book3s_xive.c
+++ b/arch/powerpc/kvm/book3s_xive.c
@@ -1928,7 +1928,7 @@ int kvmppc_xive_set_nr_servers(struct kvmppc_xive *xive, u64 addr)
pr_devel("%s nr_servers=%u\n", __func__, nr_servers);
- if (!nr_servers || nr_servers > KVM_MAX_VCPU_ID)
+ if (!nr_servers || nr_servers > KVM_MAX_VCPU_IDS)
return -EINVAL;
mutex_lock(&xive->lock);
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index b4e6f70b97b9..8ab90ce8738f 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -649,7 +649,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
r = KVM_MAX_VCPUS;
break;
case KVM_CAP_MAX_VCPU_ID:
- r = KVM_MAX_VCPU_ID;
+ r = KVM_MAX_VCPU_IDS;
break;
#ifdef CONFIG_PPC_BOOK3S_64
case KVM_CAP_PPC_GET_SMMU_INFO:
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index f8f48a7ec577..261b7d857fc0 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -50,7 +50,7 @@
* so ratio of 4 should be enough.
*/
#define KVM_VCPU_ID_RATIO 4
-#define KVM_MAX_VCPU_ID (KVM_MAX_VCPUS * KVM_VCPU_ID_RATIO)
+#define KVM_MAX_VCPU_IDS (KVM_MAX_VCPUS * KVM_VCPU_ID_RATIO)
/* memory slots that are not exposed to userspace */
#define KVM_PRIVATE_MEM_SLOTS 3
diff --git a/arch/x86/kvm/ioapic.c b/arch/x86/kvm/ioapic.c
index 698969e18fe3..3358123be946 100644
--- a/arch/x86/kvm/ioapic.c
+++ b/arch/x86/kvm/ioapic.c
@@ -96,7 +96,7 @@ static unsigned long ioapic_read_indirect(struct kvm_ioapic *ioapic,
static void rtc_irq_eoi_tracking_reset(struct kvm_ioapic *ioapic)
{
ioapic->rtc_status.pending_eoi = 0;
- bitmap_zero(ioapic->rtc_status.dest_map.map, KVM_MAX_VCPU_ID);
+ bitmap_zero(ioapic->rtc_status.dest_map.map, KVM_MAX_VCPU_IDS);
}
static void kvm_rtc_eoi_tracking_restore_all(struct kvm_ioapic *ioapic);
diff --git a/arch/x86/kvm/ioapic.h b/arch/x86/kvm/ioapic.h
index 27e61ff3ac3e..e66e620c3bed 100644
--- a/arch/x86/kvm/ioapic.h
+++ b/arch/x86/kvm/ioapic.h
@@ -39,13 +39,13 @@ struct kvm_vcpu;
struct dest_map {
/* vcpu bitmap where IRQ has been sent */
- DECLARE_BITMAP(map, KVM_MAX_VCPU_ID);
+ DECLARE_BITMAP(map, KVM_MAX_VCPU_IDS);
/*
* Vector sent to a given vcpu, only valid when
* the vcpu's bit in map is set
*/
- u8 vectors[KVM_MAX_VCPU_ID];
+ u8 vectors[KVM_MAX_VCPU_IDS];
};
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 28ef14155726..fec43997522b 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4070,7 +4070,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
r = KVM_MAX_VCPUS;
break;
case KVM_CAP_MAX_VCPU_ID:
- r = KVM_MAX_VCPU_ID;
+ r = KVM_MAX_VCPU_IDS;
break;
case KVM_CAP_PV_MMU: /* obsolete */
r = 0;
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 041ca7f15ea4..d2b405170f6e 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -39,8 +39,8 @@
#include <asm/kvm_host.h>
#include <linux/kvm_dirty_ring.h>
-#ifndef KVM_MAX_VCPU_ID
-#define KVM_MAX_VCPU_ID KVM_MAX_VCPUS
+#ifndef KVM_MAX_VCPU_IDS
+#define KVM_MAX_VCPU_IDS KVM_MAX_VCPUS
#endif
/*
diff --git a/tools/testing/selftests/kvm/kvm_create_max_vcpus.c b/tools/testing/selftests/kvm/kvm_create_max_vcpus.c
index 0299cd81b8ba..f968dfd4ee88 100644
--- a/tools/testing/selftests/kvm/kvm_create_max_vcpus.c
+++ b/tools/testing/selftests/kvm/kvm_create_max_vcpus.c
@@ -53,7 +53,7 @@ int main(int argc, char *argv[])
kvm_max_vcpu_id = kvm_max_vcpus;
TEST_ASSERT(kvm_max_vcpu_id >= kvm_max_vcpus,
- "KVM_MAX_VCPU_ID (%d) must be at least as large as KVM_MAX_VCPUS (%d).",
+ "KVM_MAX_VCPU_IDS (%d) must be at least as large as KVM_MAX_VCPUS (%d).",
kvm_max_vcpu_id, kvm_max_vcpus);
test_vcpu_creation(0, kvm_max_vcpus);
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 439d3b4cd1a9..62fcbc897e1c 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -3557,7 +3557,7 @@ static int kvm_vm_ioctl_create_vcpu(struct kvm *kvm, u32 id)
struct kvm_vcpu *vcpu;
struct page *page;
- if (id >= KVM_MAX_VCPU_ID)
+ if (id >= KVM_MAX_VCPU_IDS)
return -EINVAL;
mutex_lock(&kvm->lock);
--
2.26.2
^ permalink raw reply related [flat|nested] 27+ messages in thread* Re: [PATCH 2/2] kvm: rename KVM_MAX_VCPU_ID to KVM_MAX_VCPU_IDS
2021-09-13 13:57 ` Juergen Gross
@ 2021-09-13 16:24 ` Sean Christopherson
-1 siblings, 0 replies; 27+ messages in thread
From: Sean Christopherson @ 2021-09-13 16:24 UTC (permalink / raw)
To: Juergen Gross
Cc: kvm, x86, linux-doc, linux-kernel, linux-mips, kvm-ppc,
linuxppc-dev, linux-kselftest, Paolo Bonzini, Jonathan Corbet,
Huacai Chen, Aleksandar Markovic, Thomas Bogendoerfer,
Paul Mackerras, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Vitaly Kuznetsov, Wanpeng Li, Jim Mattson,
Joerg Roedel, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
H. Peter Anvin, Shuah Khan, Shuah Khan, Eduardo Habkost
On Mon, Sep 13, 2021, Juergen Gross wrote:
> KVM_MAX_VCPU_ID is not specifying the highest allowed vcpu-id, but the
> number of allowed vcpu-ids. This has already led to confusion, so
> rename KVM_MAX_VCPU_ID to KVM_MAX_VCPU_IDS to make its semantics more
> clear
My hesitation with this rename is that the max _number_ of IDs is not the same
thing as the max allowed ID. E.g. on x86, given a capability that enumerates the
max number of IDs, I would expect to be able to create vCPUs with arbitrary 32-bit
x2APIC IDs so long as the total number of IDs is below the max.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 2/2] kvm: rename KVM_MAX_VCPU_ID to KVM_MAX_VCPU_IDS
@ 2021-09-13 16:24 ` Sean Christopherson
0 siblings, 0 replies; 27+ messages in thread
From: Sean Christopherson @ 2021-09-13 16:24 UTC (permalink / raw)
To: Juergen Gross
Cc: x86, Wanpeng Li, kvm, linux-doc, linux-kernel, Paul Mackerras,
linux-kselftest, H. Peter Anvin, Shuah Khan, Jonathan Corbet,
Joerg Roedel, Huacai Chen, Aleksandar Markovic, Ingo Molnar,
Eduardo Habkost, kvm-ppc, Borislav Petkov, Shuah Khan,
Thomas Gleixner, Jim Mattson, Thomas Bogendoerfer, linux-mips,
Paolo Bonzini, Vitaly Kuznetsov, linuxppc-dev
On Mon, Sep 13, 2021, Juergen Gross wrote:
> KVM_MAX_VCPU_ID is not specifying the highest allowed vcpu-id, but the
> number of allowed vcpu-ids. This has already led to confusion, so
> rename KVM_MAX_VCPU_ID to KVM_MAX_VCPU_IDS to make its semantics more
> clear
My hesitation with this rename is that the max _number_ of IDs is not the same
thing as the max allowed ID. E.g. on x86, given a capability that enumerates the
max number of IDs, I would expect to be able to create vCPUs with arbitrary 32-bit
x2APIC IDs so long as the total number of IDs is below the max.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 2/2] kvm: rename KVM_MAX_VCPU_ID to KVM_MAX_VCPU_IDS
2021-09-13 16:24 ` Sean Christopherson
(?)
@ 2021-09-13 16:56 ` Eduardo Habkost
-1 siblings, 0 replies; 27+ messages in thread
From: Eduardo Habkost @ 2021-09-13 16:56 UTC (permalink / raw)
To: Sean Christopherson
Cc: Juergen Gross, kvm, x86, linux-doc, linux-kernel, linux-mips,
kvm-ppc, linuxppc-dev, linux-kselftest, Paolo Bonzini,
Jonathan Corbet, Huacai Chen, Aleksandar Markovic,
Thomas Bogendoerfer, Paul Mackerras, Michael Ellerman,
Benjamin Herrenschmidt, Paul Mackerras, Vitaly Kuznetsov,
Wanpeng Li, Jim Mattson, Joerg Roedel, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, Shuah Khan,
Shuah Khan
On Mon, Sep 13, 2021 at 12:24 PM Sean Christopherson <seanjc@google.com> wrote:
>
> On Mon, Sep 13, 2021, Juergen Gross wrote:
> > KVM_MAX_VCPU_ID is not specifying the highest allowed vcpu-id, but the
> > number of allowed vcpu-ids. This has already led to confusion, so
> > rename KVM_MAX_VCPU_ID to KVM_MAX_VCPU_IDS to make its semantics more
> > clear
>
> My hesitation with this rename is that the max _number_ of IDs is not the same
> thing as the max allowed ID. E.g. on x86, given a capability that enumerates the
> max number of IDs, I would expect to be able to create vCPUs with arbitrary 32-bit
> x2APIC IDs so long as the total number of IDs is below the max.
>
What name would you suggest instead? KVM_VCPU_ID_LIMIT, maybe?
I'm assuming we are not going to redefine KVM_MAX_VCPU_ID to be an
inclusive limit.
--
Eduardo
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 2/2] kvm: rename KVM_MAX_VCPU_ID to KVM_MAX_VCPU_IDS
@ 2021-09-13 16:56 ` Eduardo Habkost
0 siblings, 0 replies; 27+ messages in thread
From: Eduardo Habkost @ 2021-09-13 16:56 UTC (permalink / raw)
To: Sean Christopherson
Cc: x86, Wanpeng Li, kvm, linux-doc, linux-kernel, Paul Mackerras,
linux-kselftest, H. Peter Anvin, Shuah Khan, Jonathan Corbet,
Joerg Roedel, Huacai Chen, Aleksandar Markovic, Ingo Molnar,
kvm-ppc, Borislav Petkov, Shuah Khan, Thomas Gleixner,
Jim Mattson, Juergen Gross, Thomas Bogendoerfer, linux-mips,
Paolo Bonzini, Vitaly Kuznetsov, linuxppc-dev
On Mon, Sep 13, 2021 at 12:24 PM Sean Christopherson <seanjc@google.com> wrote:
>
> On Mon, Sep 13, 2021, Juergen Gross wrote:
> > KVM_MAX_VCPU_ID is not specifying the highest allowed vcpu-id, but the
> > number of allowed vcpu-ids. This has already led to confusion, so
> > rename KVM_MAX_VCPU_ID to KVM_MAX_VCPU_IDS to make its semantics more
> > clear
>
> My hesitation with this rename is that the max _number_ of IDs is not the same
> thing as the max allowed ID. E.g. on x86, given a capability that enumerates the
> max number of IDs, I would expect to be able to create vCPUs with arbitrary 32-bit
> x2APIC IDs so long as the total number of IDs is below the max.
>
What name would you suggest instead? KVM_VCPU_ID_LIMIT, maybe?
I'm assuming we are not going to redefine KVM_MAX_VCPU_ID to be an
inclusive limit.
--
Eduardo
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 2/2] kvm: rename KVM_MAX_VCPU_ID to KVM_MAX_VCPU_IDS
@ 2021-09-13 16:56 ` Eduardo Habkost
0 siblings, 0 replies; 27+ messages in thread
From: Eduardo Habkost @ 2021-09-13 16:56 UTC (permalink / raw)
To: Sean Christopherson
Cc: Juergen Gross, kvm, x86, linux-doc, linux-kernel, linux-mips,
kvm-ppc, linuxppc-dev, linux-kselftest, Paolo Bonzini,
Jonathan Corbet, Huacai Chen, Aleksandar Markovic,
Thomas Bogendoerfer, Paul Mackerras, Michael Ellerman,
Benjamin Herrenschmidt, Paul Mackerras, Vitaly Kuznetsov,
Wanpeng Li, Jim Mattson, Joerg Roedel, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, Shuah Khan,
Shuah Khan
On Mon, Sep 13, 2021 at 12:24 PM Sean Christopherson <seanjc@google.com> wrote:
>
> On Mon, Sep 13, 2021, Juergen Gross wrote:
> > KVM_MAX_VCPU_ID is not specifying the highest allowed vcpu-id, but the
> > number of allowed vcpu-ids. This has already led to confusion, so
> > rename KVM_MAX_VCPU_ID to KVM_MAX_VCPU_IDS to make its semantics more
> > clear
>
> My hesitation with this rename is that the max _number_ of IDs is not the same
> thing as the max allowed ID. E.g. on x86, given a capability that enumerates the
> max number of IDs, I would expect to be able to create vCPUs with arbitrary 32-bit
> x2APIC IDs so long as the total number of IDs is below the max.
>
What name would you suggest instead? KVM_VCPU_ID_LIMIT, maybe?
I'm assuming we are not going to redefine KVM_MAX_VCPU_ID to be an
inclusive limit.
--
Eduardo
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 2/2] kvm: rename KVM_MAX_VCPU_ID to KVM_MAX_VCPU_IDS
2021-09-13 16:56 ` Eduardo Habkost
@ 2021-09-13 18:21 ` Sean Christopherson
-1 siblings, 0 replies; 27+ messages in thread
From: Sean Christopherson @ 2021-09-13 18:21 UTC (permalink / raw)
To: Eduardo Habkost
Cc: Juergen Gross, kvm, x86, linux-doc, linux-kernel, linux-mips,
kvm-ppc, linuxppc-dev, linux-kselftest, Paolo Bonzini,
Jonathan Corbet, Huacai Chen, Aleksandar Markovic,
Thomas Bogendoerfer, Paul Mackerras, Michael Ellerman,
Benjamin Herrenschmidt, Paul Mackerras, Vitaly Kuznetsov,
Wanpeng Li, Jim Mattson, Joerg Roedel, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, Shuah Khan,
Shuah Khan
On Mon, Sep 13, 2021, Eduardo Habkost wrote:
> On Mon, Sep 13, 2021 at 12:24 PM Sean Christopherson <seanjc@google.com> wrote:
> >
> > On Mon, Sep 13, 2021, Juergen Gross wrote:
> > > KVM_MAX_VCPU_ID is not specifying the highest allowed vcpu-id, but the
> > > number of allowed vcpu-ids. This has already led to confusion, so
> > > rename KVM_MAX_VCPU_ID to KVM_MAX_VCPU_IDS to make its semantics more
> > > clear
> >
> > My hesitation with this rename is that the max _number_ of IDs is not the same
> > thing as the max allowed ID. E.g. on x86, given a capability that enumerates the
> > max number of IDs, I would expect to be able to create vCPUs with arbitrary 32-bit
> > x2APIC IDs so long as the total number of IDs is below the max.
> >
>
> What name would you suggest instead? KVM_VCPU_ID_LIMIT, maybe?
>
> I'm assuming we are not going to redefine KVM_MAX_VCPU_ID to be an
> inclusive limit.
Heh, I haven't been able to come up with one, which is why I suggested the route
of making it an inclusive value internally within KVM.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 2/2] kvm: rename KVM_MAX_VCPU_ID to KVM_MAX_VCPU_IDS
@ 2021-09-13 18:21 ` Sean Christopherson
0 siblings, 0 replies; 27+ messages in thread
From: Sean Christopherson @ 2021-09-13 18:21 UTC (permalink / raw)
To: Eduardo Habkost
Cc: x86, Wanpeng Li, kvm, linux-doc, linux-kernel, Paul Mackerras,
linux-kselftest, H. Peter Anvin, Shuah Khan, Jonathan Corbet,
Joerg Roedel, Huacai Chen, Aleksandar Markovic, Ingo Molnar,
kvm-ppc, Borislav Petkov, Shuah Khan, Thomas Gleixner,
Jim Mattson, Juergen Gross, Thomas Bogendoerfer, linux-mips,
Paolo Bonzini, Vitaly Kuznetsov, linuxppc-dev
On Mon, Sep 13, 2021, Eduardo Habkost wrote:
> On Mon, Sep 13, 2021 at 12:24 PM Sean Christopherson <seanjc@google.com> wrote:
> >
> > On Mon, Sep 13, 2021, Juergen Gross wrote:
> > > KVM_MAX_VCPU_ID is not specifying the highest allowed vcpu-id, but the
> > > number of allowed vcpu-ids. This has already led to confusion, so
> > > rename KVM_MAX_VCPU_ID to KVM_MAX_VCPU_IDS to make its semantics more
> > > clear
> >
> > My hesitation with this rename is that the max _number_ of IDs is not the same
> > thing as the max allowed ID. E.g. on x86, given a capability that enumerates the
> > max number of IDs, I would expect to be able to create vCPUs with arbitrary 32-bit
> > x2APIC IDs so long as the total number of IDs is below the max.
> >
>
> What name would you suggest instead? KVM_VCPU_ID_LIMIT, maybe?
>
> I'm assuming we are not going to redefine KVM_MAX_VCPU_ID to be an
> inclusive limit.
Heh, I haven't been able to come up with one, which is why I suggested the route
of making it an inclusive value internally within KVM.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 2/2] kvm: rename KVM_MAX_VCPU_ID to, KVM_MAX_VCPU_IDS
@ 2021-09-14 15:59 ` Christian Zigotzky
0 siblings, 0 replies; 27+ messages in thread
From: Christian Zigotzky @ 2021-09-14 15:59 UTC (permalink / raw)
To: Juergen Gross
Cc: x86, Wanpeng Li, mad skateman, kvm, linux-doc, linux-kernel,
Darren Stevens, Paul Mackerras, linux-kselftest, H. Peter Anvin,
Shuah Khan, Jonathan Corbet, Joerg Roedel, Huacai Chen, ,
Aleksandar Markovic, , Ingo Molnar, R.T.Dickinson, kvm-ppc,
Borislav Petkov, Shuah Khan, Thomas Gleixner, Jim Mattson,
Thomas Bogendoerfer, , linux-mips, Paolo Bonzini,
Vitaly, Kuznetsov, linuxppc-dev
Hello Juergen,
Hello All,
Since the RC1 of kernel 5.13, -smp 2 and -smp 4 don't work with a
virtual e5500 QEMU KVM-HV machine anymore. [1]
I see in the serial console, that the uImage doesn't load. I use the
following QEMU command for booting:
qemu-system-ppc64 -M ppce500 -cpu e5500 -enable-kvm -m 1024 -kernel
uImage -drive format=raw,file=MintPPC32-X5000.img,index=0,if=virtio
-netdev user,id=mynet0 -device virtio-net,netdev=mynet0 -append "rw
root=/dev/vda" -device virtio-vga -device virtio-mouse-pci -device
virtio-keyboard-pci -device pci-ohci,id=newusb -device
usb-audio,bus=newusb.0 -smp 4
The kernels boot without KVM-HV.
Summary for KVM-HV:
-smp 1 -> works
-smp 2 -> doesn't work
-smp 3 -> works
-smp 4 -> doesn't work
I used -smp 4 before the RC1 of kernel 5.13 because my FSL P5040 BookE
machine [2] has 4 cores.
Does this patch solve this issue? [3]
Thanks,
Christian
[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-May/229103.html
[2] http://wiki.amiga.org/index.php?title=X5000
[3]
https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-September/234152.html
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 2/2] kvm: rename KVM_MAX_VCPU_ID to, KVM_MAX_VCPU_IDS
@ 2021-09-14 15:59 ` Christian Zigotzky
0 siblings, 0 replies; 27+ messages in thread
From: Christian Zigotzky @ 2021-09-14 15:59 UTC (permalink / raw)
To: Juergen Gross
Cc: x86, Wanpeng Li, mad skateman, kvm, linux-doc, linux-kernel,
Darren Stevens, Paul Mackerras, linux-kselftest, H. Peter Anvin,
Shuah Khan, Jonathan Corbet, Joerg Roedel, Huacai Chen, ,
Aleksandar Markovic, , Ingo Molnar, R.T.Dickinson, kvm-ppc,
Borislav Petkov, Shuah Khan, Thomas Gleixner, Jim Mattson,
Thomas Bogendoerfer, , linux-mips, Paolo Bonzini,
Vitaly, Kuznetsov, linuxppc-dev
Hello Juergen,
Hello All,
Since the RC1 of kernel 5.13, -smp 2 and -smp 4 don't work with a
virtual e5500 QEMU KVM-HV machine anymore. [1]
I see in the serial console, that the uImage doesn't load. I use the
following QEMU command for booting:
qemu-system-ppc64 -M ppce500 -cpu e5500 -enable-kvm -m 1024 -kernel
uImage -drive format=raw,file=MintPPC32-X5000.img,index=0,if=virtio
-netdev user,id=mynet0 -device virtio-net,netdev=mynet0 -append "rw
root=/dev/vda" -device virtio-vga -device virtio-mouse-pci -device
virtio-keyboard-pci -device pci-ohci,id=newusb -device
usb-audio,bus=newusb.0 -smp 4
The kernels boot without KVM-HV.
Summary for KVM-HV:
-smp 1 -> works
-smp 2 -> doesn't work
-smp 3 -> works
-smp 4 -> doesn't work
I used -smp 4 before the RC1 of kernel 5.13 because my FSL P5040 BookE
machine [2] has 4 cores.
Does this patch solve this issue? [3]
Thanks,
Christian
[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-May/229103.html
[2] http://wiki.amiga.org/index.php?title=X5000
[3]
https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-September/234152.html
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 2/2] kvm: rename KVM_MAX_VCPU_ID to, KVM_MAX_VCPU_IDS
@ 2021-09-14 15:59 ` Christian Zigotzky
0 siblings, 0 replies; 27+ messages in thread
From: Christian Zigotzky @ 2021-09-14 15:59 UTC (permalink / raw)
To: Juergen Gross
Cc: kvm, x86, linux-doc, linux-kernel, linux-mips, kvm-ppc,
linuxppc-dev, linux-kselftest, Paolo Bonzini, Jonathan Corbet,
Huacai Chen,, Aleksandar Markovic,, Thomas Bogendoerfer,,
Paul Mackerras, Michael Ellerman, Benjamin Herrenschmidt,,
Paul Mackerras, Vitaly, Kuznetsov, Wanpeng Li, Jim Mattson,
Joerg Roedel, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
H. Peter Anvin, Shuah Khan, Shuah Khan, R.T.Dickinson,
Darren Stevens, mad skateman
Hello Juergen,
Hello All,
Since the RC1 of kernel 5.13, -smp 2 and -smp 4 don't work with a
virtual e5500 QEMU KVM-HV machine anymore. [1]
I see in the serial console, that the uImage doesn't load. I use the
following QEMU command for booting:
qemu-system-ppc64 -M ppce500 -cpu e5500 -enable-kvm -m 1024 -kernel
uImage -drive format=raw,file=MintPPC32-X5000.img,index=0,if=virtio
-netdev user,id=mynet0 -device virtio-net,netdev=mynet0 -append "rw
root=/dev/vda" -device virtio-vga -device virtio-mouse-pci -device
virtio-keyboard-pci -device pci-ohci,id=newusb -device
usb-audio,bus=newusb.0 -smp 4
The kernels boot without KVM-HV.
Summary for KVM-HV:
-smp 1 -> works
-smp 2 -> doesn't work
-smp 3 -> works
-smp 4 -> doesn't work
I used -smp 4 before the RC1 of kernel 5.13 because my FSL P5040 BookE
machine [2] has 4 cores.
Does this patch solve this issue? [3]
Thanks,
Christian
[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-May/229103.html
[2] http://wiki.amiga.org/index.php?title=X5000
[3]
https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-September/234152.html
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 2/2] kvm: rename KVM_MAX_VCPU_ID to, KVM_MAX_VCPU_IDS
2021-09-14 15:59 ` Christian Zigotzky
(?)
@ 2022-07-05 16:07 ` Christian Zigotzky
-1 siblings, 0 replies; 27+ messages in thread
From: Christian Zigotzky @ 2022-07-05 16:07 UTC (permalink / raw)
To: Juergen Gross
Cc: kvm, x86, linux-doc, linux-kernel, linux-mips, kvm-ppc,
linuxppc-dev, linux-kselftest, Paolo Bonzini, Jonathan Corbet,
Huacai Chen,, Aleksandar Markovic,, Thomas Bogendoerfer,,
Paul Mackerras, Michael Ellerman, Benjamin Herrenschmidt,,
Paul Mackerras, Vitaly, Kuznetsov, Wanpeng Li, Jim Mattson,
Joerg Roedel, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
H. Peter Anvin, Shuah Khan, Shuah Khan, R.T.Dickinson,
Darren Stevens, mad skateman
On 14 September 2021 at 05:59 pm, Christian Zigotzky wrote:
> Hello Juergen,
> Hello All,
>
> Since the RC1 of kernel 5.13, -smp 2 and -smp 4 don't work with a
> virtual e5500 QEMU KVM-HV machine anymore. [1]
> I see in the serial console, that the uImage doesn't load. I use the
> following QEMU command for booting:
>
> qemu-system-ppc64 -M ppce500 -cpu e5500 -enable-kvm -m 1024 -kernel
> uImage -drive format=raw,file=MintPPC32-X5000.img,index=0,if=virtio
> -netdev user,id=mynet0 -device virtio-net,netdev=mynet0 -append "rw
> root=/dev/vda" -device virtio-vga -device virtio-mouse-pci -device
> virtio-keyboard-pci -device pci-ohci,id=newusb -device
> usb-audio,bus=newusb.0 -smp 4
>
> The kernels boot without KVM-HV.
>
> Summary for KVM-HV:
>
> -smp 1 -> works
> -smp 2 -> doesn't work
> -smp 3 -> works
> -smp 4 -> doesn't work
>
> I used -smp 4 before the RC1 of kernel 5.13 because my FSL P5040 BookE
> machine [2] has 4 cores.
>
> Does this patch solve this issue? [3]
>
> Thanks,
> Christian
>
> [1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-May/229103.html
> [2] http://wiki.amiga.org/index.php?title=X5000
> [3]
> https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-September/234152.html
Hello,
Since the RC5 of kernel 5.19, -smp 2 and -smp 4 work again. I don't know
which patch has solved the issue.
Cheers,
Christian
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 2/2] kvm: rename KVM_MAX_VCPU_ID to, KVM_MAX_VCPU_IDS
@ 2022-07-05 16:07 ` Christian Zigotzky
0 siblings, 0 replies; 27+ messages in thread
From: Christian Zigotzky @ 2022-07-05 16:07 UTC (permalink / raw)
To: Juergen Gross
Cc: x86, Wanpeng Li, mad skateman, kvm, linux-doc, linux-kernel,
Darren Stevens, Paul Mackerras, linux-kselftest, H. Peter Anvin,
Shuah Khan, Jonathan Corbet, Joerg Roedel, Huacai Chen,,
Aleksandar Markovic,, Ingo Molnar, R.T.Dickinson, kvm-ppc,
Borislav Petkov, Shuah Khan, Thomas Gleixner, Jim Mattson,
Thomas Bogendoerfer,, linux-mips, Paolo Bonzini,
Vitaly, Kuznetsov, linuxppc-dev
On 14 September 2021 at 05:59 pm, Christian Zigotzky wrote:
> Hello Juergen,
> Hello All,
>
> Since the RC1 of kernel 5.13, -smp 2 and -smp 4 don't work with a
> virtual e5500 QEMU KVM-HV machine anymore. [1]
> I see in the serial console, that the uImage doesn't load. I use the
> following QEMU command for booting:
>
> qemu-system-ppc64 -M ppce500 -cpu e5500 -enable-kvm -m 1024 -kernel
> uImage -drive format=raw,file=MintPPC32-X5000.img,index=0,if=virtio
> -netdev user,id=mynet0 -device virtio-net,netdev=mynet0 -append "rw
> root=/dev/vda" -device virtio-vga -device virtio-mouse-pci -device
> virtio-keyboard-pci -device pci-ohci,id=newusb -device
> usb-audio,bus=newusb.0 -smp 4
>
> The kernels boot without KVM-HV.
>
> Summary for KVM-HV:
>
> -smp 1 -> works
> -smp 2 -> doesn't work
> -smp 3 -> works
> -smp 4 -> doesn't work
>
> I used -smp 4 before the RC1 of kernel 5.13 because my FSL P5040 BookE
> machine [2] has 4 cores.
>
> Does this patch solve this issue? [3]
>
> Thanks,
> Christian
>
> [1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-May/229103.html
> [2] http://wiki.amiga.org/index.php?title=X5000
> [3]
> https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-September/234152.html
Hello,
Since the RC5 of kernel 5.19, -smp 2 and -smp 4 work again. I don't know
which patch has solved the issue.
Cheers,
Christian
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 2/2] kvm: rename KVM_MAX_VCPU_ID to, KVM_MAX_VCPU_IDS
@ 2022-07-05 16:07 ` Christian Zigotzky
0 siblings, 0 replies; 27+ messages in thread
From: Christian Zigotzky @ 2022-07-05 16:07 UTC (permalink / raw)
To: Juergen Gross
Cc: kvm, x86, linux-doc, linux-kernel, linux-mips, kvm-ppc,
linuxppc-dev, linux-kselftest, Paolo Bonzini, Jonathan Corbet,
Huacai Chen,, Aleksandar Markovic,, Thomas Bogendoerfer,,
Paul Mackerras, Michael Ellerman, Benjamin Herrenschmidt,,
Paul Mackerras, Vitaly, Kuznetsov, Wanpeng Li, Jim Mattson,
Joerg Roedel, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
H. Peter Anvin, Shuah Khan, Shuah Khan, R.T.Dickinson,
Darren Stevens, mad skateman
On 14 September 2021 at 05:59 pm, Christian Zigotzky wrote:
> Hello Juergen,
> Hello All,
>
> Since the RC1 of kernel 5.13, -smp 2 and -smp 4 don't work with a
> virtual e5500 QEMU KVM-HV machine anymore. [1]
> I see in the serial console, that the uImage doesn't load. I use the
> following QEMU command for booting:
>
> qemu-system-ppc64 -M ppce500 -cpu e5500 -enable-kvm -m 1024 -kernel
> uImage -drive format=raw,file=MintPPC32-X5000.img,index=0,if=virtio
> -netdev user,id=mynet0 -device virtio-net,netdev=mynet0 -append "rw
> root=/dev/vda" -device virtio-vga -device virtio-mouse-pci -device
> virtio-keyboard-pci -device pci-ohci,id=newusb -device
> usb-audio,bus=newusb.0 -smp 4
>
> The kernels boot without KVM-HV.
>
> Summary for KVM-HV:
>
> -smp 1 -> works
> -smp 2 -> doesn't work
> -smp 3 -> works
> -smp 4 -> doesn't work
>
> I used -smp 4 before the RC1 of kernel 5.13 because my FSL P5040 BookE
> machine [2] has 4 cores.
>
> Does this patch solve this issue? [3]
>
> Thanks,
> Christian
>
> [1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-May/229103.html
> [2] http://wiki.amiga.org/index.php?title=X5000
> [3]
> https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-September/234152.html
Hello,
Since the RC5 of kernel 5.19, -smp 2 and -smp 4 work again. I don't know
which patch has solved the issue.
Cheers,
Christian
^ permalink raw reply [flat|nested] 27+ messages in thread