Re: [PATCH 08/11] arm: virt: create GWDT watchdog paired with WDAT ACPI table

[Igor Mammedov <imammedo@redhat.com>]

On Thu, 19 Feb 2026 13:00:13 +0000
Peter Maydell <peter.maydell@linaro.org> wrote:

> On Thu, 19 Feb 2026 at 12:17, Igor Mammedov <imammedo@redhat.com> wrote:
> >
> > On Wed, 18 Feb 2026 19:08:36 +0000
> > Peter Maydell <peter.maydell@linaro.org> wrote:  
> 
> > > Please can you also add support for exposing this device
> > > in the device tree ?  
> >
> > It's possible,
> > but we probably should not enable it if acpi variant was requested,
> > to avoid confusion on guest side.  
> 
> Why? Almost every other device on this board we advertise
> via DTB for device tree guests and via ACPI for ACPI guests.
If we expose both guest may try to load both drivers causing conflict or misbehavior.
(
that's what x86 solved by quirk on guest side preferring WDAT watchdog
instead of native one.
)
I can try and see what arm kernel would do in presence if both
but that's not the point.
(my guess is that only 1st loaded driver would succeed, the rest
would fail on claimed resources)

One should consider plain GWDT whatchdog as a different device
when compared to WDAT one.
The later one is basically an synthetic watchdog with it's own driver.
From guest pov they are different devices (using the same registers/irqs).

exposing only one watchdog in fw (DT or ACPI), lets user pick a preferred one
without need to hack guest kernel with a quirk.

> (The exceptions are things like the CXL handling that really
> only has an ACPI representation and can't be described in the DTB.) 
> > For Windows it doesn't really mater, for linux it does.
> > on x86 linux guest uses a quirk to disable native iTCO watchdog
> > in favor of WDAT one if later is present.
> > I assume quirk is not desirable so we should expose only a preferred
> > variant.  
> 
> For this Arm board there is no watchdog except the one you're
> adding in this patch, though.
> 
> > > Can we have a command line option name that isn't ACPI
> > > specific, please? There's nothing inherent to ACPI about
> > > "I would like a watchdog device".  
> >
> > that is specifically asking for ACPI flavor being used/configured.
> > acpi specific option conflates 2 things:
> >    1. watchdog device creation (of the board choice) with properties tuned for WDAT usage
> >    2. how to expose it on firmware level (in this case ACPI WDAT table)  
> 
> Right, and I think that's the wrong way to approach this,
> at least for the virt board. We should either always create
> or allow the user to ask us to create a watchdog device.
> And then we should do what we do for all the other devices,
> which is expose it via both the mechanisms that we have
> for telling the guest about hardware (ACPI and DTB).

Looks like I wasn't clear, WDAT is not a description
of the hardware watchdog. It's a 'abstract watchdog device',
that uses a set IO/MMIO operations from WDAT table to manage
whatever hardware watchdog board provides. Guest uses WDAT
specific driver to manage it.

Windows and Linux[1] use it without need for hardware specific driver.
All hardware specific details are encoded in WDAT table provided by board.

q35 would provide its own WDAT for underling TCO watchdog
while virt-arm would provide GWDT specific WDAT.

From guest pov it's the same WDAT watchdog, and guest doesn't
need any other watchdog drivers beside WDAT one.


machine.watchdog = (on|off) will handle/expose native watchdog whatever it is.
but with this user won't be able to pick wdat/acpi watchdog.

would following enum be acceptable?

machine.watchdog {
  "on" or "native", 
  "off",
  "acpi" or "wdat"
}

1) https://lkml.iu.edu/hypermail/linux/kernel/1609.1/04003.html

> 
> thanks
> -- PMM
>