LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Joao Martins <joao.m.martins@oracle.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "Thomas Gleixner" <tglx@linutronix.de>,
	"y2038 Mailman List" <y2038@lists.linaro.org>,
	"Ingo Molnar" <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"the arch/x86 maintainers" <x86@kernel.org>,
	"Jan Kiszka" <jan.kiszka@siemens.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>,
	"Boris Ostrovsky" <boris.ostrovsky@oracle.com>,
	"Juergen Gross" <jgross@suse.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Borislav Petkov" <bp@suse.de>,
	"Andy Lutomirski" <luto@kernel.org>,
	"John Stultz" <john.stultz@linaro.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	jailhouse-dev@googlegroups.com, kvm@vger.kernel.org,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH] [v3] x86: Convert x86_platform_ops to timespec64
Date: Wed, 2 May 2018 17:44:47 +0100	[thread overview]
Message-ID: <92ef9d3a-d2bc-59db-de43-4845a46fd2d8@oracle.com> (raw)
In-Reply-To: <CAK8P3a0T8RkPgHm6F+Y+RHBdi7v5ho1hQ8w+MwWFcOk5TbMaCw@mail.gmail.com>

On 04/28/2018 11:09 AM, Arnd Bergmann wrote:
> On Sat, Apr 28, 2018 at 12:21 AM, Joao Martins
> <joao.m.martins@oracle.com> wrote:
>> On 04/27/2018 09:13 PM, Arnd Bergmann wrote:
>>> diff --git a/arch/x86/kernel/pvclock.c b/arch/x86/kernel/pvclock.c
>>> index 761f6af6efa5..637982efecd8 100644
>>> --- a/arch/x86/kernel/pvclock.c
>>> +++ b/arch/x86/kernel/pvclock.c
>>> @@ -123,28 +123,35 @@ u64 pvclock_clocksource_read(struct pvclock_vcpu_time_info *src)
>>>
>>>  void pvclock_read_wallclock(struct pvclock_wall_clock *wall_clock,
>>>                           struct pvclock_vcpu_time_info *vcpu_time,
>>> -                         struct timespec *ts)
>>> +                         struct timespec64 *ts)
>>>  {
>>>       u32 version;
>>>       u64 delta;
>>> -     struct timespec now;
>>> +     struct timespec64 now;
>>>
>>>       /* get wallclock at system boot */
>>>       do {
>>>               version = wall_clock->version;
>>>               rmb();          /* fetch version before time */
>>> +             /*
>>> +              * Note: wall_clock->sec is a u32 value, so it can
>>> +              * only store dates between 1970 and 2106. To allow
>>> +              * times beyond that, we need to create a new hypercall
>>> +              * interface with an extended pvclock_wall_clock structure
>>> +              * like ARM has.
>>> +              */
>>>               now.tv_sec  = wall_clock->sec;
>>
>> IIUC the interface you're probably speaking about is common to both ARM and x86
>> on Xen[*] (since Xen 4.6) i.e.
>>
>>         now.tv_sec  = ((uint64_t)s->wc_sec_hi << 32) | s->wc_sec;
>>
>> s representing struct shared_info like on ARM (there's a 32-bit hole where
>> wc_sec_hi is placed on x86_64/ARM). Except on x86 32-bit guests wc_sec_hi is
>> located elsewhere.
>>
>>         Joao
>>
>> [*]
>> https://xenbits.xen.org/docs/4.6-testing/hypercall/x86_64/include,public,xen.h.html#incontents_startofday_shared
> 
> Ah, good. How portable is that? Will it do the right thing (i.e.
> guarantee to have
> zeroes on the upper half, or the epoch if supported) on all versions of both KVM
> and Xen, or do we need an additional check in there?
>
The whole shared info page is zeroed out by Xen when allocated, so on
unsupported platforms that includes the upper half. But I don't know if this is
considered ABI or not. FWIW, the oldest release (2.0) has that behavior.

But this is Xen that I'm speaking about; KVM doesn't support this IIUC.

On KVM, there's HC_CLOCK_PAIRING hypercall or else *maybe* host could just write
wc_sec_hi at the end of the wall_clock struct (with the current MSR) and given
that it's (PAGE_SIZE aligned) guest memory, guest could always keep it zeroed
out for unsupported platforms (that won't write more than 12bytes).

> I'd suggest leaving the implementation of that to a follow-up patch that you
> can add once my patch is merged.

/nods

	Joao

  reply	other threads:[~2018-05-02 16:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-27 20:13 Arnd Bergmann
2018-04-27 20:56 ` Radim Krčmář
2018-04-27 22:21 ` Joao Martins
2018-04-28 10:09   ` Arnd Bergmann
2018-05-02 16:44     ` Joao Martins [this message]
2018-04-28  7:25 ` Jan Kiszka
2018-05-19 12:06 ` [tip:timers/2038] " tip-bot for Arnd Bergmann

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=92ef9d3a-d2bc-59db-de43-4845a46fd2d8@oracle.com \
    --to=joao.m.martins@oracle.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=boris.ostrovsky@oracle.com \
    --cc=bp@suse.de \
    --cc=hpa@zytor.com \
    --cc=jailhouse-dev@googlegroups.com \
    --cc=jan.kiszka@siemens.com \
    --cc=jgross@suse.com \
    --cc=john.stultz@linaro.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rkrcmar@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    --cc=y2038@lists.linaro.org \
    --subject='Re: [PATCH] [v3] x86: Convert x86_platform_ops to timespec64' \
    /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

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).