From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Julien Grall <julien.grall@citrix.com>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
xen-devel@lists.xensource.com
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [PATCH 2/2] arm: export platform_op XENPF_settime
Date: Thu, 5 Nov 2015 18:00:34 +0000 [thread overview]
Message-ID: <563B9942.6050601@citrix.com> (raw)
In-Reply-To: <563B9339.2080606@citrix.com>
On 05/11/15 17:34, Julien Grall wrote:
> Hi Stefano,
>
> You forgot to CC Daniel for the XSM part. Please use
> scripts/get_maintainers.pl to get the relevant maintainers.
>
> On 05/11/15 16:57, Stefano Stabellini wrote:
>> Call update_domain_wallclock_time at domain initialization.
> It's not really what you are doing in the code. You are calling
> update_domain_wallclock_time when the first vCPU is initialized.
>
> Also some rationale to explain why this call should be done here would
> be good.
>
> Finally, I'm a bit surprised that you only need to call
> update_domain_wallclock_time when the domain is created. x86 needs to
> call in various places.
>
> For instance we may want to call update_domain_wallclock_time in
> construct_dom0 before clearing the pause flags. This is because the
> wallclock may be out of sync as construction DOM0 takes some time.
Just as a note for the x86 side of things, I am planning to see whether
it is possible to remove all (real) RTC knowledge from Xen.
Nothing in Xen actually needs to know wallclock time (other than just
propagating what dom0 says to other domains). It can safely be ignored
until dom0 has made a settime hypercall.
Currently the RTC and CMOS ram is shared between Xen and dom0, in a way
which is basically impossible to actually lock down. Removing the RTC
as a source of wallclock time allows Xen to give the RTC wholesale to
dom0, which removes quite a lot of complexity.
Furthermore, it removes all use of gettime EFI call, which is known
buggy in just about all currently-available firmware, and will
definitely be an improvement.
~Andrew
next prev parent reply other threads:[~2015-11-05 18:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-05 16:56 [PATCH 0/2] wallclock time on arm Stefano Stabellini
2015-11-05 16:57 ` [PATCH 1/2] xen: move wallclock functions from x86 to common Stefano Stabellini
2015-11-05 17:17 ` Julien Grall
2015-11-05 17:18 ` Jan Beulich
2015-11-06 17:45 ` Stefano Stabellini
2015-11-05 16:57 ` [PATCH 2/2] arm: export platform_op XENPF_settime Stefano Stabellini
2015-11-05 17:04 ` David Vrabel
2015-11-06 12:21 ` Stefano Stabellini
2015-11-05 17:34 ` Julien Grall
2015-11-05 18:00 ` Andrew Cooper [this message]
2015-11-09 17:09 ` Stefano Stabellini
2015-11-10 14:11 ` Julien Grall
2015-11-10 14:27 ` Stefano Stabellini
2015-11-10 14:41 ` Julien Grall
2015-11-11 17:09 ` Stefano Stabellini
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=563B9942.6050601@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=dgdegra@tycho.nsa.gov \
--cc=ian.campbell@citrix.com \
--cc=julien.grall@citrix.com \
--cc=stefano.stabellini@eu.citrix.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.