All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Thomas Leonard <talex5@gmail.com>,
	Samuel Thibault <samuel.thibault@ens-lyon.org>,
	keir@xen.org
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: mini-os: x86: virtual-timer interrupt and get_time_values_from_xen
Date: Tue, 21 Oct 2014 11:38:49 +0100	[thread overview]
Message-ID: <1413887929.23337.20.camel@citrix.com> (raw)
In-Reply-To: <CAG4opy-fLbB17OOCH5RRWMOrab=Fpbur_vu_z4BoFgo-wss0zQ@mail.gmail.com>

(adding some CCs, and not trimming quotes for their benefit)

On Fri, 2014-10-17 at 15:12 +0100, Thomas Leonard wrote:
> In Mini-OS on x86 we have:
> 
> static void timer_handler(evtchn_port_t ev, struct pt_regs *regs, void *ign)
> {
>     get_time_values_from_xen();
>     update_wallclock();
> }
> 
> static evtchn_port_t port;
> void init_time(void)
> {
>     printk("Initialising timer interface\n");
>     port = bind_virq(VIRQ_TIMER, &timer_handler, NULL);
>     unmask_evtchn(port);
> }
> 
> It seems that the timer values are only correct after the first timer
> interrupt occurs. For example, test.c can output this (if you remove
> xenbus_tester so it starts the timer test quickly enough):
> 
>     Periodic thread started.
>     T(s=8734 us=790808)
>     T(s=1413543796 us=487564)
>     T(s=1413543797 us=487867)
>     ...
> 
> I can fix this by getting it to read the values in init_time:
> 
> void init_time(void)
> {
>     printk("Initialising timer interface\n");
>     port = bind_virq(VIRQ_TIMER, &timer_handler, NULL);
>     unmask_evtchn(port);
> 
>     get_time_values_from_xen();
>     update_wallclock();
> }
> 
> But now I wonder whether the code in timer_handler is needed at all.
> It seems that all code that reads the timer already ensures these
> values are up-to-date by comparing the version number (presumably this
> doesn't work the first time because shadow isn't initialised). With
> the fix to init_time, is it safe to use an empty handler?

It seems like you might be right wrt get_time_values_from_xen(), since
the shadow struct is static to this file all users must be in there, and
on inspection it does seem like everything is always up to date.
(get_nsec_offset appears not, but it's only caller takes care of it).

However I think the update_wallclock is needed, since gettimeofday
doesn't force the update of shadow_ts (nb: different thing to shadow).
Essentially it uses the monotonic_clock to interpolate between timer
ticks.

Ian.

  reply	other threads:[~2014-10-21 10:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-17 14:12 mini-os: x86: virtual-timer interrupt and get_time_values_from_xen Thomas Leonard
2014-10-21 10:38 ` Ian Campbell [this message]
2014-10-21 21:46   ` Samuel Thibault

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=1413887929.23337.20.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=keir@xen.org \
    --cc=samuel.thibault@ens-lyon.org \
    --cc=talex5@gmail.com \
    --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 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.