Re: [PATCH for-4.22 3/5] x86/vRTC: support century field

[Jan Beulich <jbeulich@suse.com>]

On 13.05.2026 16:58, Jan Beulich wrote:
> On 13.05.2026 16:24, Roger Pau Monné wrote:
>> On Tue, May 12, 2026 at 04:59:35PM +0200, Jan Beulich wrote:
>>> Both ROMBIOS and SeaBIOS (with CONFIG_QEMU=y, as we build it) blindly
>>> assume availability of this field (at its conventional index 0x32); OVMF
>>> at least has code to inspect FADT. Hence we ought to have supported it
>>> virtually forever.
>>>
>>> As the index is beyond RTC_CMOS_SIZE, leverage the padding field in
>>> struct hvm_hw_rtc to hold its value. Update the field only when involved
>>> values are valid BCD century specifiers. Otherwise (for VMs migrated in
>>> from an older hypervisor) leave handling to the DM.
>>>
>>> This makes the Linux rtc-cmos driver report y3k compatibility.
>>>
>>> While extending xen-hvmctx.c:dump_rtc() also add RTC offset there.
>>>
>>> Fixes: 4ca161214355 ("[HVM] Move RTC emulation into the hypervisor")
>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>> ---
>>> Am I overly paranoid with the checking of the field, considering that
>>> Xen 3.x post-dates year 2000 and hence all firmware nowadays usable guests
>>> have ever run with should have been aware of the field? Or am I, quite the
>>> opposite, still not strict enough?
>>>
>>> I can't help the impression that this introduces a latency issue for
>>> the 2nd of gmtime()'s while() loops: We now allow years up into the 99th
>>> century, i.e. over 8000 years away from 1970. 8000 years are very roughly
>>> 2^^38 seconds, making for (again very roughly) 5 million iterations there.
>>> Did I get my math wrong, or do we need a prereq change to (vastly) reduce
>>> the number of iterations of that loop (e.g. along the lines of the other
>>> one, first going in 400 year steps)?
>>
>> Hm, maybe we need to add some XTF testing for the RTC?  I'm slightly
>> worried how much time this could take, and since those calls are
>> serialized on the s->lock I wonder whether enough parallel accesses
>> from the guest could manage to trigger the watchdog?
> 
> I'm not really up to making an XTF test, I guess. However, as you look to
> share my concern, I'll add a prereq patch adjusting gmtime().

While making such a patch, I noticed my flaw in the description above: That
loop walks in granularity of years, so can't have more than about 10k
iterations. Shortening the processing by first going in 400-year steps may
still be worthwhile, but doesn't look to be strictly required.

Jan