From: Fabiano Rosas <farosas@linux.ibm.com>
To: Christophe Leroy <christophe.leroy@csgroup.eu>, kvm-ppc@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org, groug@kaod.org,
david@gibson.dropbear.id.au
Subject: Re: [RFC PATCH 2/2] KVM: PPC: Book3S HV: Provide a more accurate MAX_VCPU_ID in P9
Date: Tue, 08 Mar 2022 14:27:32 +0000 [thread overview]
Message-ID: <87lexka59n.fsf@linux.ibm.com> (raw)
In-Reply-To: <f5ec9d55-bac3-b571-dfad-bd501cd364b3@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 13/04/2021 à 00:26, Fabiano Rosas a écrit :
>> The KVM_CAP_MAX_VCPU_ID capability was added by commit 0b1b1dfd52a6
>> ("kvm: introduce KVM_MAX_VCPU_ID") to allow for vcpu ids larger than
>> KVM_MAX_VCPU in powerpc.
>>
>> For a P9 host we depend on the guest VSMT value to know what is the
>> maximum number of vcpu id we can support:
>>
>> kvmppc_core_vcpu_create_hv:
>> (...)
>> if (cpu_has_feature(CPU_FTR_ARCH_300)) {
>> --> if (id >= (KVM_MAX_VCPUS * kvm->arch.emul_smt_mode)) {
>> pr_devel("KVM: VCPU ID too high\n");
>> core = KVM_MAX_VCORES;
>> } else {
>> BUG_ON(kvm->arch.smt_mode != 1);
>> core = kvmppc_pack_vcpu_id(kvm, id);
>> }
>> } else {
>> core = id / kvm->arch.smt_mode;
>> }
>>
>> which means that the value being returned by the capability today for
>> a given guest is potentially way larger than what we actually support:
>>
>> \#define KVM_MAX_VCPU_ID (MAX_SMT_THREADS * KVM_MAX_VCORES)
>>
>> If the capability is queried before userspace enables the
>> KVM_CAP_PPC_SMT ioctl there is not much we can do, but if the emulated
>> smt mode is already known we could provide a more accurate value.
>>
>> The only practical effect of this change today is to make the
>> kvm_create_max_vcpus test pass for powerpc. The QEMU spapr machine has
>> a lower max vcpu than what KVM allows so even KVM_MAX_VCPU is not
>> reached.
>>
>> Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
>
> This patch won't apply after commit a1c42ddedf35 ("kvm: rename
> KVM_MAX_VCPU_ID to KVM_MAX_VCPU_IDS")
>
> Feel free to resubmit if still applicable.
Thanks for the reminder, Christophe.
I was focusing on enabling the rest of the kvm-selftests:
https://lore.kernel.org/r/20220120170109.948681-1-farosas@linux.ibm.com
I'm preparing a v2 for that series and will try to include these patches
as well.
WARNING: multiple messages have this Message-ID (diff)
From: Fabiano Rosas <farosas@linux.ibm.com>
To: Christophe Leroy <christophe.leroy@csgroup.eu>, kvm-ppc@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org, groug@kaod.org,
david@gibson.dropbear.id.au
Subject: Re: [RFC PATCH 2/2] KVM: PPC: Book3S HV: Provide a more accurate MAX_VCPU_ID in P9
Date: Tue, 08 Mar 2022 11:27:32 -0300 [thread overview]
Message-ID: <87lexka59n.fsf@linux.ibm.com> (raw)
In-Reply-To: <f5ec9d55-bac3-b571-dfad-bd501cd364b3@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 13/04/2021 à 00:26, Fabiano Rosas a écrit :
>> The KVM_CAP_MAX_VCPU_ID capability was added by commit 0b1b1dfd52a6
>> ("kvm: introduce KVM_MAX_VCPU_ID") to allow for vcpu ids larger than
>> KVM_MAX_VCPU in powerpc.
>>
>> For a P9 host we depend on the guest VSMT value to know what is the
>> maximum number of vcpu id we can support:
>>
>> kvmppc_core_vcpu_create_hv:
>> (...)
>> if (cpu_has_feature(CPU_FTR_ARCH_300)) {
>> --> if (id >= (KVM_MAX_VCPUS * kvm->arch.emul_smt_mode)) {
>> pr_devel("KVM: VCPU ID too high\n");
>> core = KVM_MAX_VCORES;
>> } else {
>> BUG_ON(kvm->arch.smt_mode != 1);
>> core = kvmppc_pack_vcpu_id(kvm, id);
>> }
>> } else {
>> core = id / kvm->arch.smt_mode;
>> }
>>
>> which means that the value being returned by the capability today for
>> a given guest is potentially way larger than what we actually support:
>>
>> \#define KVM_MAX_VCPU_ID (MAX_SMT_THREADS * KVM_MAX_VCORES)
>>
>> If the capability is queried before userspace enables the
>> KVM_CAP_PPC_SMT ioctl there is not much we can do, but if the emulated
>> smt mode is already known we could provide a more accurate value.
>>
>> The only practical effect of this change today is to make the
>> kvm_create_max_vcpus test pass for powerpc. The QEMU spapr machine has
>> a lower max vcpu than what KVM allows so even KVM_MAX_VCPU is not
>> reached.
>>
>> Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
>
> This patch won't apply after commit a1c42ddedf35 ("kvm: rename
> KVM_MAX_VCPU_ID to KVM_MAX_VCPU_IDS")
>
> Feel free to resubmit if still applicable.
Thanks for the reminder, Christophe.
I was focusing on enabling the rest of the kvm-selftests:
https://lore.kernel.org/r/20220120170109.948681-1-farosas@linux.ibm.com
I'm preparing a v2 for that series and will try to include these patches
as well.
next prev parent reply other threads:[~2022-03-08 14:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-12 22:26 [RFC PATCH 0/2] kvm selftests and MAX_VCPU_ID Fabiano Rosas
2021-04-12 22:26 ` Fabiano Rosas
2021-04-12 22:26 ` [RFC PATCH 1/2] KVM: selftests: Add max vcpus test for ppc64le Fabiano Rosas
2021-04-12 22:26 ` Fabiano Rosas
2021-04-12 22:26 ` [RFC PATCH 2/2] KVM: PPC: Book3S HV: Provide a more accurate MAX_VCPU_ID in P9 Fabiano Rosas
2021-04-12 22:26 ` Fabiano Rosas
2022-03-08 13:34 ` Christophe Leroy
2022-03-08 13:34 ` Christophe Leroy
2022-03-08 14:27 ` Fabiano Rosas [this message]
2022-03-08 14:27 ` Fabiano Rosas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lexka59n.fsf@linux.ibm.com \
--to=farosas@linux.ibm.com \
--cc=christophe.leroy@csgroup.eu \
--cc=david@gibson.dropbear.id.au \
--cc=groug@kaod.org \
--cc=kvm-ppc@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.