On 21/01/2026 14:06, Jan Beulich wrote: > On 21.01.2026 14:02, Tu Dinh wrote: >> Hello, >> >> On 21/01/2026 10:17, Jan Beulich wrote: >>> 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? >>> >> >> In this case, it's not because the vRTC emulation was wrong, but rather >> because Windows's internal wallclock is not Xen-aware > > And it shouldn't need to be. > >> and needs to be >> synchronized after some Xen-specific events. So it's more of an >> accommodation for Windows guests. >> >> Also, Windows timekeeping integrates closely with its internal time >> service, which assumes a NTP-like interface (and thus an external time >> reference). The current way of time synchronization in the Windows PV >> drivers doesn't work well in this model, which is why I'm looking for a >> way to get the external time reference from Xen. > > Are you suggesting then that plain Windows is fine, but Windows with the > PV drivers isn't? That would look to be an issue with the PV drivers then, > wouldn't it? >
No, it just means that Windows running on Xen without PV drivers is not fine, and the PV drivers currently need this feature in order to correctly sync the guest time. This new functionality will be used in the Windows PV drivers if it were to be merged. > Jan -- Ngoc Tu Dinh | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech
