From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Borislav Petkov <bp@suse.de>,
Xiaoyao Li <xiaoyao.li@intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
KVM list <kvm@vger.kernel.org>
Subject: Re: [GIT PULL] First batch of KVM changes for 5.6 merge window
Date: Fri, 31 Jan 2020 10:53:42 -0800 [thread overview]
Message-ID: <20200131185341.GA18946@linux.intel.com> (raw)
In-Reply-To: <CAHk-=wjZTUq8u0HZUJ1mKZjb-haBFhX+mKcUv3Kdh9LQb8rg4g@mail.gmail.com>
On Fri, Jan 31, 2020 at 10:01:37AM -0800, Linus Torvalds wrote:
> On Thu, Jan 30, 2020 at 10:20 AM Paolo Bonzini <pbonzini@redhat.com> wrote:
> >
> > Xiaoyao Li (3):
> > KVM: VMX: Rename INTERRUPT_PENDING to INTERRUPT_WINDOW
> > KVM: VMX: Rename NMI_PENDING to NMI_WINDOW
> > KVM: VMX: Fix the spelling of CPU_BASED_USE_TSC_OFFSETTING
>
> So in the meantime, on the x86 merge window side, we have this:
>
> b39033f504a7 ("KVM: VMX: Use VMX_FEATURE_* flags to define VMCS control bits")
>
> and while the above results in a conflict, that's not a problem. The
> conflict was trivial to fix up.
>
> HOWEVER.
>
> It most definitely shows that the above renaming now means that the
> names don't match. It didn't match 100% before either, but now the
> differences are even bigger. The VMX_FEATURE_xyz bits have different
> names than the CPU_BASED_xyz bits, and that seems a bit questionable.
>
> So I'm not convinced about the renaming. The spelling fix is good: it
> actually now more closely resembles the VMCS_FEATURE bit that already
> had OFFSETTING with two T's.
>
> But even that one isn't really the same even then. The CPU_BASED_xyz
> thing has "USE_TSC_OFFSETTING", while the VMCS_FEATURE_xyz bit doesn't
> have the "USE" part.
>
> And the actual renaming means that now we basically have
>
> CPU_BASED_INTR_WINDOW_EXITING
> VMX_FEATURE_VIRTUAL_INTR_PENDING
>
> and
>
> CPU_BASED_NMI_WINDOW_EXITING
> VMX_FEATURE_VIRTUAL_NMI_PENDING
>
> for the same bit definitions (yeah, the VMX_FEATURE bits obviously
> have the offset in them, so it's not the same _value_, but it's a 1:1
> relationship between them).
>
> There are other (pre-existing) differences, but while fixing up the
> merge conflict I really got the feeling that it's confusing and wrong
> to basically use different naming for these things when they are about
> the same bit.
>
> I don't care much which way it goes (maybe the VMX_FATURE_xyz bits
> should be renamed instead of the other way around?) and I wonder what
> the official documentation names are? Is there some standard here or
> are people just picking names at random?
>
> The two commits both came from intel.com addresses, so hopefully there
> can be some intel-sanctioned resolution on the naming? Please?
Hrm.
For *_WINDOW_EXITING versus VIRTUAL_*_PENDING, VMX_FEATURE_* should be
renamed to use *_WINDOW_EXITING, as that's the nomenclature used by the
SDM. I added the VMX_FEATURE_* names while KVM was still using
VIRTUAL_*_PENDING, and neglected to go back and update the series, probably
because I was in denial after lobbying to keep the non-SDM names[1] and
getting overruled[2] :-).
As for USE_TSC_OFFSETTING vs TSC_OFFSETTING, I'd like to keep the minor
differences. VMX_FEATURES is intended to reflect the capabilities of the
CPU, whereas the CPU_BASED/EXEC masks are effectively "commands" from
software to hardware, e.g. "CPU has TSC offsetting" vs. "CPU, use TSC
offsetting".
Re-reading vmxfeatures.h, I botched a few names:
USE_IO_BITMAPS and USE_MSR_BITMAPS shouldn't have the USE_ prefix, by my
own capability vs. command argument.
PAGE_MOD_LOGGING should simply be PML. I have no idea why I chose to
(partially) expand the acronym.
I assume the easiest thing would be send a cleanup patch for vmxfeatures.h
and route it through the KVM tree?
[1] https://lkml.kernel.org/r/20191206204747.GD5433@linux.intel.com/
[2] https://lkml.kernel.org/r/2beeb1fb-7d3a-d829-38e0-ddf76b65bd3c@redhat.com/
next prev parent reply other threads:[~2020-01-31 18:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-30 18:20 [GIT PULL] First batch of KVM changes for 5.6 merge window Paolo Bonzini
2020-01-31 18:01 ` Linus Torvalds
2020-01-31 18:53 ` Sean Christopherson [this message]
2020-01-31 19:03 ` Linus Torvalds
2020-01-31 21:08 ` Paolo Bonzini
2020-01-31 21:24 ` Borislav Petkov
2020-01-31 21:27 ` Paolo Bonzini
2020-01-31 19:35 ` pr-tracker-bot
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=20200131185341.GA18946@linux.intel.com \
--to=sean.j.christopherson@intel.com \
--cc=bp@suse.de \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=torvalds@linux-foundation.org \
--cc=xiaoyao.li@intel.com \
/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.