From: Sean Christopherson <seanjc@google.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Juergen Gross <jgross@suse.com>,
kvm@vger.kernel.org, x86@kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org,
kvm-ppc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-kselftest@vger.kernel.org,
Paolo Bonzini <pbonzini@redhat.com>,
Jonathan Corbet <corbet@lwn.net>,
Huacai Chen <chenhuacai@kernel.org>,
Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Paul Mackerras <paulus@ozlabs.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>, Shuah Khan <shuah@kernel.org>,
Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [PATCH 2/2] kvm: rename KVM_MAX_VCPU_ID to KVM_MAX_VCPU_IDS
Date: Mon, 13 Sep 2021 18:21:25 +0000 [thread overview]
Message-ID: <YT+WpdnGodZE9krY@google.com> (raw)
In-Reply-To: <CAOpTY_pyeOo2Kh-r1cEFk2XL4g8A1mxQpP1y62thWk2mh6XUUg@mail.gmail.com>
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.
WARNING: multiple messages have this Message-ID (diff)
From: Sean Christopherson <seanjc@google.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: x86@kernel.org, Wanpeng Li <wanpengli@tencent.com>,
kvm@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
linux-kselftest@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Shuah Khan <shuah@kernel.org>, Jonathan Corbet <corbet@lwn.net>,
Joerg Roedel <joro@8bytes.org>,
Huacai Chen <chenhuacai@kernel.org>,
Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>,
Ingo Molnar <mingo@redhat.com>,
kvm-ppc@vger.kernel.org, Borislav Petkov <bp@alien8.de>,
Shuah Khan <skhan@linuxfoundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Jim Mattson <jmattson@google.com>,
Juergen Gross <jgross@suse.com>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
linux-mips@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 2/2] kvm: rename KVM_MAX_VCPU_ID to KVM_MAX_VCPU_IDS
Date: Mon, 13 Sep 2021 18:21:25 +0000 [thread overview]
Message-ID: <YT+WpdnGodZE9krY@google.com> (raw)
In-Reply-To: <CAOpTY_pyeOo2Kh-r1cEFk2XL4g8A1mxQpP1y62thWk2mh6XUUg@mail.gmail.com>
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.
next prev parent reply other threads:[~2021-09-13 18:21 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-13 13:57 [PATCH 0/2] kvm: fix KVM_MAX_VCPU_ID handling Juergen Gross
2021-09-13 13:57 ` Juergen Gross
2021-09-13 13:57 ` Juergen Gross
2021-09-13 13:57 ` [PATCH 1/2] x86/kvm: revert commit 76b4f357d0e7d8f6f00 Juergen Gross
2021-11-08 20:14 ` Ben Gardon
2021-11-08 20:15 ` Ben Gardon
2021-11-09 8:46 ` Juergen Gross
2021-11-09 17:15 ` Ben Gardon
2021-09-13 13:57 ` [PATCH 2/2] kvm: rename KVM_MAX_VCPU_ID to KVM_MAX_VCPU_IDS Juergen Gross
2021-09-13 13:57 ` Juergen Gross
2021-09-13 13:57 ` Juergen Gross
2021-09-13 16:24 ` Sean Christopherson
2021-09-13 16:24 ` Sean Christopherson
2021-09-13 16:56 ` Eduardo Habkost
2021-09-13 16:56 ` Eduardo Habkost
2021-09-13 16:56 ` Eduardo Habkost
2021-09-13 18:21 ` Sean Christopherson [this message]
2021-09-13 18:21 ` Sean Christopherson
2021-09-23 16:21 ` [PATCH 0/2] kvm: fix KVM_MAX_VCPU_ID handling Paolo Bonzini
2021-09-23 16:21 ` Paolo Bonzini
2021-09-23 16:21 ` Paolo Bonzini
2021-09-14 15:59 [PATCH 2/2] kvm: rename KVM_MAX_VCPU_ID to, KVM_MAX_VCPU_IDS Christian Zigotzky
2021-09-14 15:59 ` Christian Zigotzky
2021-09-14 15:59 ` Christian Zigotzky
2022-07-05 16:07 ` Christian Zigotzky
2022-07-05 16:07 ` Christian Zigotzky
2022-07-05 16:07 ` Christian Zigotzky
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=YT+WpdnGodZE9krY@google.com \
--to=seanjc@google.com \
--cc=aleksandar.qemu.devel@gmail.com \
--cc=benh@kernel.crashing.org \
--cc=bp@alien8.de \
--cc=chenhuacai@kernel.org \
--cc=corbet@lwn.net \
--cc=ehabkost@redhat.com \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=paulus@ozlabs.org \
--cc=paulus@samba.org \
--cc=pbonzini@redhat.com \
--cc=shuah@kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=tglx@linutronix.de \
--cc=tsbogend@alpha.franken.de \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
--cc=x86@kernel.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.