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.
next prev parent 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.