Re: [PATCH v3 17/17] sbsa-gwdt: limit compare_value to INT64_MAX

[Igor Mammedov <imammedo@redhat.com>]

On Mon, 29 Jun 2026 15:48:48 +0100
Peter Maydell <peter.maydell@linaro.org> wrote:

> On Wed, 24 Jun 2026 at 11:29, Igor Mammedov <imammedo@redhat.com> wrote:
> >
> > QEMU timer subsystem uses int64_t, so WCV values with bit 63 set
> > overflow and cause the timer to fire immediately. The SBSA spec
> > defines WCV as an unsigned 64-bit compare value, so such values
> > are valid per spec and represent far-future deadlines (however
> > unpractical).
> >
> > Windows in GTDT mode writes WCV in two 32-bit halves while the
> > watchdog is running:
> >
> >  sbsa-gwdt_control_write [0x8]  <- 0xffffffff    # WOR (~4 sec)
> >  sbsa-gwdt_control_write [0x0]  <- 0x1           # WCS enable
> >  sbsa-gwdt_control_write [0x14] <- 0xffffffff    # WCVU (intermediate)
> >  sbsa-gwdt_control_write [0x10] <- 0xa906ca28    # WCVL
> >  sbsa-gwdt_control_write [0x14] <- 0xecb1        # WCVU (final)
> >
> > The intermediate WCVU write (0xffffffff) creates a WCV above
> > INT64_MAX, which overflows QEMU's signed timer and fires
> > immediately — triggering WS0 => WS1 => reboot before the final
> > WCVU write lands.
> >
> > Clamp WCV to INT64_MAX to avoid timer API overflow.  
> 
> This bug doesn't exist as described in the current upstream
> version of this device, because we don't use WCVU/WCVL in
> calculating the timeout (only WORU/WORL, which are forced to
> 48 bits wide on write). This suggests that either you have
> introduced it in this series, in which case it would be better
> to not do that, or else that it exists in a different form
> in current upstream, in which case it would be better to
> fix it first in the patchset, so it can be cc:stable for
> backports.

it's masked by missing timer reschedule on WCV update,
that preceding patch #16 fixes.
So yes it's ordering issue.

perhaps it's better split this patches into independed series,
given that the last 14-17 patches are fixing native GWDT
behavior for Windows usecase (which would still not work
due to too large timeouts)
and that it's not directly related to this series (linux uses
normal refresh approach with native gwdt mode), and WDAT mode
peddled by this series work fine with both Windows and Linux.

With the last 4 patches we still need to convince MS to fix large
timeouts on their side to make native gwdt work as expected.


> 
> thanks
> -- PMM
>