On Mon, May 11, 2026 at 09:06:54AM +0200, Paolo Bonzini wrote:
> On 1/14/26 02:32, Jinjie Ruan wrote:
> > In get_guest_rtc_ns(), "s->base_rtc" is uint64_t, which multiplied by
> > "NANOSECONDS_PER_SECOND" may overflow the uint64_t type, which will
> > cause the QEMU Linux Virtual Machine's RTC time to jump and in turn
> > triggers a kernel Soft Lockup and ultimately leads to a crash.
> >
> > Fix it by avoiding adding s->base_rtc in get_guest_rtc_ns_offset(),
> > because get_guest_rtc_ns() is used either take the remainder of
> > NANOSECONDS_PER_SECOND or take the quotient of NANOSECONDS_PER_SECOND.
> >
> > Fixes: 56038ef6234e ("RTC: Update the RTC clock only when reading it")
> > Signed-off-by: Jinjie Ruan <[email protected]>
>
> Thanks, queued - I also renamed the function to
> get_rtc_ns_since_last_update(). It's not entirely accurate due the presence
> of the sub-second offset s->offset, but it's good enough.
>
> I have also considered changing the function to return a struct timespec. I
> didn't like it too much because struct timespec uses a time_t which is
> possibly 32-bit. Now, QEMU is probably broken for Y2038 anyway, but having
> time_t dependencies in device emulation code is not great; at least mktimegm
> and gmtime_r could be rewritten easily.
For system mode at least, we can assume time_t will be 64-bit only
since we drop 32-bit host OS support.
For user mode, we can likewise assume 64-bit host OS, but still have
to deal with potential 32-bit time_t for the guest OS. One could
argue that in the user mode case though, the guest ABI is what is
broken for Y2038 - QEMU is just honouring the (broken) ABI that is
defined.
The tools could be impacted by 32-bit issues I guess, but we still
have 10+ years to kill off the 32-bit host OS build support for
tools
With regards,
Daniel
--
|: https://berrange.com ~~ https://hachyderm.io/@berrange :|
|: https://libvirt.org ~~ https://entangle-photo.org :|
|: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
