All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@novell.com>
To: Keir Fraser <keir.xen@gmail.com>
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"winston.l.wang" <winston.l.wang@intel.com>
Subject: Re: [PATCH] x86: don't write_tsc() non-zero values on CPUs updating only the lower 32 bits
Date: Thu, 14 Apr 2011 08:42:07 +0100	[thread overview]
Message-ID: <4DA6C16F020000780003B899@vpn.id2.novell.com> (raw)
In-Reply-To: <C9CC6014.164FF%keir.xen@gmail.com>

>>> On 14.04.11 at 09:25, Keir Fraser <keir.xen@gmail.com> wrote:
> On 14/04/2011 08:18, "Jan Beulich" <JBeulich@novell.com> wrote:
> 
>> This means suppressing the uses in time_calibration_tsc_rendezvous(),
>> cstate_restore_tsc(), and synchronize_tsc_slave(), and fixes a boot
>> hang of Linux Dom0 when loading processor.ko on such systems that
>> have support for C states above C1.
> 
> Should your new test be gated on !X86_FEATURE_TSC_RELIABLE? We already

Which test? The write-TSC-probe itself?

> *never* write the TSC when boot_cpu_has(TSC_RELIABLE) -- Dan Magenheimer
> made that change on the assumption that TSCs were globally synced by
> firmware in this case, and us writing one or more TSCs could only ever make
> things worse.

That's not true - we only avoid the writing for TSC sync during boot.
Post-boot bringup of CPUs will write the TSC no matter what, and
cstate_restore_tsc() also has no such gating afaics.

Jan

  reply	other threads:[~2011-04-14  7:42 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-14  7:18 [PATCH] x86: don't write_tsc() non-zero values on CPUs updating only the lower 32 bits Jan Beulich
2011-04-14  7:25 ` Keir Fraser
2011-04-14  7:42   ` Jan Beulich [this message]
2011-04-14  7:50     ` Keir Fraser
2011-04-14  8:06       ` Jan Beulich
2011-04-14  9:18         ` Keir Fraser
2011-04-14 22:41           ` Dan Magenheimer
2011-04-15  6:40             ` Keir Fraser
2011-04-15 14:34               ` Dan Magenheimer
2011-04-15 17:28                 ` Keir Fraser
2011-04-14  7:28 ` Jan Beulich
2011-04-14 16:05 ` Keir Fraser
2011-04-14 16:28   ` Jan Beulich
2011-04-14 16:48     ` Keir Fraser
2011-04-14 18:33       ` Wang, Winston L
2011-04-14 21:06         ` Keir Fraser
2011-04-14 21:37           ` Wang, Winston L
2011-04-15  7:06           ` Jan Beulich
2011-04-15  7:08       ` Jan Beulich
2011-04-15  7:37         ` Keir Fraser
2011-04-15 14:49           ` Wang, Winston L

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=4DA6C16F020000780003B899@vpn.id2.novell.com \
    --to=jbeulich@novell.com \
    --cc=dan.magenheimer@oracle.com \
    --cc=keir.xen@gmail.com \
    --cc=winston.l.wang@intel.com \
    --cc=xen-devel@lists.xensource.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.