[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 2/2] arm: export platform_op XENPF_settime



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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.