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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 20.01.2026 17:06, Tu Dinh wrote:
> On 20/01/2026 16:39, Jan Beulich wrote:
>> On 20.01.2026 16:27, Tu Dinh wrote:
>>> On 20/01/2026 13:42, Jan Beulich wrote:
>>>> On 20.01.2026 13:12, Tu Dinh wrote:
>>>>> On 20/01/2026 11:35, Jan Beulich wrote:
>>>>>> On 20.01.2026 10:57, 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.
>>>>>>
>>>>>> Despite my earlier comments this part of the description looks unchanged.
>>>>>> I still don't see why host time (or in fact about any host property) 
>>>>>> should
>>>>>> be exposed to guests.
>>>>>
>>>>> I've answered this question in a followup reply from November, which
>>>>> I'll reproduce here:
>>>>
>>>> I did read your reply, yet nothing of it appeared here as additional
>>>> justification.
>>>
>>> Is the new description OK for you?
>>
>> Which new description? So far I only saw your responses to my questions, not
>> an updated patch description.
>>
> 
> Maybe my last email wasn't clear, it was in the part marked "Follow up", 
> reproduced below:
> 
> Xen currently does not expose the host's wall clock time in shared_info. 
> This means while shared_info can be used as an alternative to the 
> emulated RTC, it can't be used to keep the virtual wall clock in sync. 
> Expose the time_offset value in struct shared_info in order to allow 
> guests to synchronize their own wall clock to that of the host.
> 
> This is needed because on Windows guests, the PV drivers don't control 
> the timing of RTC updates, as this is done by the kernel itself 
> periodically. If the guest's internal clock deviates from the RTC (e.g. 
> after resuming from suspend), a RTC write would cause time_offset to 
> deviate from the supposed value (timezone offset) and thus cause the RTC 
> to become incorrect.

What I still can't extract from this is why Windows running bare-metal is
fine but Windows running on Xen's vRTC isn't. If there's a problem with
our vRTC, shouldn't that be addressed there?

Also, just ftaod: If other maintainers find this convincing, my failure to
understand shouldn't get in the way. They may still approve this change,
i.e. I'm not vetoing it. It's just that as of now I also wouldn't ack it.

Jan