All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Radim Krčmář" <rkrcmar@redhat.com>
To: Don Bowman <db@donbowman.ca>
Cc: kvm@vger.kernel.org, pbonzini@redhat.com
Subject: Re: PATCH: setup_vmcs_config: disable TSC scaling on unlike processors
Date: Mon, 5 Dec 2016 17:37:39 +0100	[thread overview]
Message-ID: <20161205163738.GA7972@potion> (raw)
In-Reply-To: <CADJev7-oFxAnRCd0Ezhe5XZs1MeU60+EcwYx2Y8GeEBNi2+9Ew@mail.gmail.com>

2016-12-02 15:58-0500, Don Bowman:
> On 2 December 2016 at 14:10, Don Bowman <db@donbowman.ca> wrote:
>> On 2 December 2016 at 10:07, Radim Krčmář <rkrcmar@redhat.com> wrote:
>>> 2016-12-01 21:32-0500, Don Bowman:
>>>> My system has what i thought were two identical processors (same
>>>> stepping ID etc).
>>>> However, bafflingly, one of them has the ability to do TSC scaling,
>>>> and one does not (as reported in the vmcs).
>>>
> OK, how about this? The check has to be in setup_vmcs_config() not
> elsewhere I think. This is where the rdmsr occurs, and immediately
> following that is the compare against the other processor(s). Unless
> I'm missing something I don't see how vmx_secondary_exec_control()
> could work. For the enable I was following the 'enable_pml' which is
> already there, but have changed it below. vmx_check_processor_compat()
> calls setup_vmcs_config() and then the memcmp() immediately
> afterwards.

Right, KVM checks this early ... I don't like that the patch treats
tsc_scaling specially while the same could happen with some other
feature.  What about warning in vmx_check_processor_compat() if features
that won't be used don't match, but letting the check pass?

(I'd even prefer an unsafe option to disable the check than to treat
 tsc_scaling differently.)

  reply	other threads:[~2016-12-05 16:37 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-02  2:32 PATCH: setup_vmcs_config: disable TSC scaling on unlike processors Don Bowman
2016-12-02 15:07 ` Radim Krčmář
2016-12-02 19:10   ` Don Bowman
2016-12-02 20:58     ` Don Bowman
2016-12-05 16:37       ` Radim Krčmář [this message]
2016-12-06  8:49   ` David Hildenbrand
2016-12-06  9:09     ` Paolo Bonzini
2016-12-06 11:08       ` Radim Krčmář
2016-12-07 11:37         ` David Hildenbrand
2016-12-07 15:25           ` Radim Krčmář
2016-12-08 11:46             ` David Hildenbrand
2016-12-08 14:32               ` Radim Krčmář
2016-12-09 15:12                 ` Don Bowman
2016-12-13 15:43                   ` Radim Krčmář
2016-12-14  4:07                     ` Don Bowman
2016-12-14 12:30                       ` Paolo Bonzini
2016-12-14 12:46                     ` Paolo Bonzini

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=20161205163738.GA7972@potion \
    --to=rkrcmar@redhat.com \
    --cc=db@donbowman.ca \
    --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.