All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Jim Mattson <jmattson@google.com>
Cc: kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH 2/3] KVM: x86: Virtualize HWCR.TscFreqSel[bit 24]
Date: Fri, 22 Sep 2023 13:51:54 -0700	[thread overview]
Message-ID: <ZQ3+auXRFAE/OiRW@google.com> (raw)
In-Reply-To: <CALMp9eQN=SMo00Xo-ekD4EF8fQjp6DqUrLedO9TbwXcPGwt3hg@mail.gmail.com>

On Fri, Sep 22, 2023, Jim Mattson wrote:
> On Fri, Sep 22, 2023 at 12:40 PM Sean Christopherson <seanjc@google.com> wrote:
> >
> > On Fri, Sep 22, 2023, Jim Mattson wrote:
> > > Okay. What about the IA32_MISC_ENABLE bits above?
> >
> > One of the exceptions where I don't see a better option, and hopefully something
> > that Intel won't repeat in the future.  Though I'm not exactly brimming with
> > confidence that Intel won't retroactively add more "gotcha! unsupported!" bits
> > in the future when they realize they forgot add a useful CPUID feature bit.
> 
> I don't understand the difference here. Why not make userspace
> responsible for setting these bits as well?

That probably would have been the ideal approach.  I'm not entirely sure it would
have actually been feasible though, as I suspect enumerting X86_FEATURE_DS without
any kind of guard would break userspace that reflects KVM_GET_SUPPORTED_CPUID
back into KVM_SET_CPUID(2).

Even better would have been to never merge PEBS support in KVM in its current
form.  The whole thing is a house of cards, e.g. if counters are "cross-mapped"
then the guest counters simply stop working.  And those warts aside, the entire
enabling was a chaotic mess.  See commit 9fc222967a39 ("KVM: x86: Give host
userspace full control of MSR_IA32_MISC_ENABLES").

In other words, setting the UNAVAILABLE bits was the least awful way to salvage
the mess.

  reply	other threads:[~2023-09-22 20:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-22 16:42 [PATCH 1/3] KVM: x86: Allow HWCR.McStatusWrEn to be cleared once set Jim Mattson
2023-09-22 16:42 ` [PATCH 2/3] KVM: x86: Virtualize HWCR.TscFreqSel[bit 24] Jim Mattson
2023-09-22 17:21   ` Sean Christopherson
2023-09-22 17:48     ` Jim Mattson
2023-09-22 18:15       ` Sean Christopherson
2023-09-22 18:27         ` Jim Mattson
2023-09-22 19:40           ` Sean Christopherson
2023-09-22 20:16             ` Jim Mattson
2023-09-22 20:51               ` Sean Christopherson [this message]
2023-09-22 16:42 ` [PATCH 3/3] KVM: selftests: Test behavior of HWCR Jim Mattson

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=ZQ3+auXRFAE/OiRW@google.com \
    --to=seanjc@google.com \
    --cc=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.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.