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
