Re: [PATCH] xen: Expose time_offset in struct arch_shared_info

[Jan Beulich <jbeulich@xxxxxxxx>]

On 12.11.2025 08:08, Tu Dinh wrote:
> time_offset is currently always added to wc_sec. This means that without
> the actual value of time_offset, guests have no way of knowing what's
> the actual host clock. Once the guest clock drifts beyond 1 second,
> updates to the guest RTC would themselves change time_offset and make it
> impossible to resync guest time to host time.

I guess I don't understand what the problem is, or why it would need a
change in the hypervisor (interface). If the guest updates the vRTC, it is
(implicitly) asking for a change of time offset, isn't it? And whatever
adjustments it makes, it could track and accumulate them?

> Since there's no way to add more fields to struct shared_info, the
> addition has to be done through struct arch_shared_info instead. Add two
> fields in arch_shared_info representing time_offset's low and high
> 32-bit halves.

Any why in two halves? Without that, ...

> --- a/xen/common/time.c
> +++ b/xen/common/time.c
> @@ -118,6 +118,11 @@ void update_domain_wallclock_time(struct domain *d)
>      shared_info(d, wc_sec_hi) = sec >> 32;
>  #endif
>  
> +    shared_info(d, arch.time_offset) =
> +        (uint32_t)(uint64_t)d->time_offset.seconds;
> +    shared_info(d, arch.time_offset_hi) =
> +        (uint32_t)((uint64_t)d->time_offset.seconds >> 32);

... no casting at all would be needed here. (Even when there are two halves,
some of the casting can be dropped.)

Another question is - why unsigned? struct domain's time_offset.seconds is
signed for a reason, aiui.

Jan