From: Jan Beulich <jbeulich@suse.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: Igor Druzhinin <igor.druzhinin@citrix.com>,
andrew.cooper3@citrix.com, wl@xen.org,
xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH] x86/time: update TSC stamp on restore from deep C-state
Date: Wed, 15 Jan 2020 13:49:22 +0100 [thread overview]
Message-ID: <c13cbf1e-2e1d-dc17-ec90-a1098a11ec58@suse.com> (raw)
In-Reply-To: <20200115115338.GL11756@Air-de-Roger>
On 15.01.2020 12:53, Roger Pau Monné wrote:
> On Wed, Jan 15, 2020 at 12:40:27PM +0100, Jan Beulich wrote:
>> On 15.01.2020 10:47, Roger Pau Monné wrote:
>>> On Tue, Jan 14, 2020 at 07:36:21PM +0000, Igor Druzhinin wrote:
>>>> --- a/xen/arch/x86/time.c
>>>> +++ b/xen/arch/x86/time.c
>>>> @@ -955,10 +955,16 @@ u64 stime2tsc(s_time_t stime)
>>>>
>>>> void cstate_restore_tsc(void)
>>>> {
>>>> + struct cpu_time *t = &this_cpu(cpu_time);
>>>> +
>>>> if ( boot_cpu_has(X86_FEATURE_NONSTOP_TSC) )
>>>> return;
>>>>
>>>> - write_tsc(stime2tsc(read_platform_stime(NULL)));
>>>> + t->stamp.master_stime = read_platform_stime(NULL);
>>>> + t->stamp.local_tsc = stime2tsc(t->stamp.master_stime);
>>>> + t->stamp.local_stime = t->stamp.master_stime;
>>>> +
>>>> + write_tsc(t->stamp.local_tsc);
>>>
>>> In order to avoid the TSC write (and the likely associated vmexit),
>>> could you instead do:
>>>
>>> t->stamp.local_stime = t->stamp.master_stime = read_platform_stime(NULL);
>>> t->stamp.local_tsc = rdtsc_ordered();
>>>
>>> I think it should achieve the same as it syncs the local TSC stamp and
>>> times, would avoid the TSC write and slightly simplifies the logic.
>>
>> Wouldn't this result in guests possibly observing the TSC moving
>> backwards?
>
> Isn't local_tsc storing a TSC value read from the same CPU always, and
> hence could only go backwards if rdtsc actually goes backwards?
For one I have to admit I was (mistakenly) thinking of wakeup
from S states more than that from C states. So assuming the
TSC indeed only stops (but won't get e.g. restarted), backwards
moves ought to be excluded. What I'm then worried about is too
little progress observable by guests. The PV time protocol
ought to be fine in this regard (and consumers of raw TSC values
are on their own anyway), but wouldn't you need to update TSC
offsets of HVM guests in order to compensate for the elapsed
time?
> Ie: cpu_frequency_change seems to do something similar, together with
> a re-adjusting of the time scale, but doesn't perform any TSC write.
A P-state change at most alters the the tick rate, but wouldn't
stop or even reset the TSC (afaict).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2020-01-15 12:49 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-14 19:36 [Xen-devel] [PATCH] x86/time: update TSC stamp on restore from deep C-state Igor Druzhinin
2020-01-15 9:47 ` Roger Pau Monné
2020-01-15 11:40 ` Jan Beulich
2020-01-15 11:53 ` Roger Pau Monné
2020-01-15 12:49 ` Jan Beulich [this message]
2020-01-15 13:44 ` Roger Pau Monné
2020-01-15 16:21 ` Jan Beulich
2020-01-16 9:33 ` Roger Pau Monné
2020-01-16 9:38 ` Jan Beulich
2020-01-16 12:09 ` Igor Druzhinin
2020-01-16 12:25 ` Roger Pau Monné
2020-01-15 12:25 ` Igor Druzhinin
2020-01-15 12:31 ` Igor Druzhinin
2020-01-15 12:41 ` Jan Beulich
2020-01-15 12:36 ` Igor Druzhinin
2020-01-15 13:23 ` Roger Pau Monné
2020-01-15 14:45 ` Igor Druzhinin
2020-01-15 11:32 ` Jan Beulich
2020-01-15 12:28 ` Igor Druzhinin
2020-01-15 12:39 ` Jan Beulich
2020-01-15 12:47 ` Igor Druzhinin
2020-01-15 12:54 ` Jan Beulich
2020-01-15 14:55 ` Andrew Cooper
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=c13cbf1e-2e1d-dc17-ec90-a1098a11ec58@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=igor.druzhinin@citrix.com \
--cc=roger.pau@citrix.com \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).