From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Igor Mammedov <imammedo@redhat.com>,
qemu-devel@nongnu.org, mst@redhat.com, anisinha@redhat.com,
pbonzini@redhat.com, shannon.zhaosl@gmail.com, philmd@linaro.org,
zhao1.liu@intel.com, rad@semihalf.com,
leif.lindholm@oss.qualcomm.com
Subject: Re: [PATCH 08/11] arm: virt: create GWDT watchdog paired with WDAT ACPI table
Date: Wed, 25 Feb 2026 15:11:03 +0000 [thread overview]
Message-ID: <aZ8RByaj4h6i2OXt@redhat.com> (raw)
In-Reply-To: <CAFEAcA_v4Y5NEiYZsTyQPt=orc8gxGJ_PWu55T_0mAt+iY4OQA@mail.gmail.com>
On Thu, Feb 19, 2026 at 04:04:37PM +0000, Peter Maydell wrote:
> On Thu, 19 Feb 2026 at 14:55, Igor Mammedov <imammedo@redhat.com> wrote:
> >
> > 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.
>
> Huh? A guest will do one of:
> 1 read the ACPI tables, and load the driver based on the ACPI data
> 2 read the DTB, and load the driver based on the DTB
>
> Nothing tries to read both at once, or it would get totally
> confused.
>
> > I can try and see what arm kernel would do in presence if both
> > but that's not the point.
>
> We know already that this works fine, because almost every
> piece of hardware in the virt board is described in both
> the dtb and the ACPI tables.
The watchdog is different though as the ACPI WDAT table is not
describing the underlying piece of hardware. Instead it is
describing an interface for controlling watchdog functionality,
such that the guest does not have any awareness of what the
underlying physical impl is.
This feels like a pretty awful characteristic of the ACPI WDAT
design, as it forces guests to do hacks like the quirk added to
iTCO :-(
If such hacks aren't possible then it forces the even worse
behaviour of QEMU mgmt apps needing to decide between multiple
different watchdog configs depending on what they know about
guest OS support :-(
Bit of a no-win scenario.
> > 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).
>
> But there is only one piece of hardware here, right?
QEMU knows that, but the guest OS does not. It cloud be one piece of
hardware in which case only 1 exposed device can be activated, or it
could be two distinct pieces of hardware both of which can be used
independently.
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 :|
next prev parent reply other threads:[~2026-02-25 15:11 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-06 13:14 [PATCH 00/11] Introduce ACPI watchdog for Q35 and arm/virt boards Igor Mammedov
2026-02-06 13:14 ` [PATCH 01/11] acpi: add API to build WDAT instructions Igor Mammedov
2026-02-16 8:12 ` Ani Sinha
2026-02-06 13:14 ` [PATCH 02/11] machine: add "acpi-watchdog" property Igor Mammedov
2026-02-16 8:23 ` Ani Sinha
2026-02-26 17:08 ` Philippe Mathieu-Daudé
2026-02-27 8:23 ` Igor Mammedov
2026-02-06 13:14 ` [PATCH 03/11] x86: q35: generate WDAT ACPI table Igor Mammedov
2026-02-16 10:51 ` Ani Sinha
2026-02-06 13:14 ` [PATCH 04/11] tests: acpi: x86/q35: whitelist new WDAT table Igor Mammedov
2026-02-16 9:50 ` Ani Sinha
2026-02-06 13:14 ` [PATCH 05/11] tests: acpi: x86/q35: add WDAT table test case Igor Mammedov
2026-02-16 9:51 ` Ani Sinha
2026-02-06 13:14 ` [PATCH 06/11] tests: acpi: x86/q35: update expected WDAT blob Igor Mammedov
2026-02-17 5:34 ` Ani Sinha
2026-02-06 13:14 ` [PATCH 07/11] arm: add tracing events to sbsa_gwdt Igor Mammedov
2026-02-16 10:22 ` Ani Sinha
2026-02-06 13:14 ` [PATCH 08/11] arm: virt: create GWDT watchdog paired with WDAT ACPI table Igor Mammedov
2026-02-18 19:08 ` Peter Maydell
2026-02-19 12:17 ` Igor Mammedov
2026-02-19 13:00 ` Peter Maydell
2026-02-19 14:55 ` Igor Mammedov
2026-02-19 16:04 ` Peter Maydell
2026-02-23 9:28 ` Igor Mammedov
2026-02-25 15:11 ` Daniel P. Berrangé [this message]
2026-02-25 15:19 ` Daniel P. Berrangé
2026-02-26 12:56 ` Igor Mammedov
2026-02-27 7:24 ` Markus Armbruster
2026-02-27 9:01 ` Daniel P. Berrangé
2026-02-27 10:01 ` Igor Mammedov
2026-02-27 10:18 ` Daniel P. Berrangé
2026-02-27 11:41 ` Igor Mammedov
2026-02-27 9:42 ` Igor Mammedov
2026-02-27 12:10 ` Markus Armbruster
2026-02-27 13:14 ` Peter Maydell
2026-02-27 14:51 ` Markus Armbruster
2026-02-27 15:01 ` Peter Maydell
2026-03-02 5:32 ` Markus Armbruster
2026-02-06 13:14 ` [PATCH 09/11] tests: acpi: arm/virt: whitelist new WDAT table Igor Mammedov
2026-02-06 13:14 ` [PATCH 10/11] tests: acpi: arm/virt: add WDAT table test case Igor Mammedov
2026-02-06 13:14 ` [PATCH 11/11] tests: acpi: arm/virt: update expected WDAT blob Igor Mammedov
2026-02-16 7:39 ` [PATCH 00/11] Introduce ACPI watchdog for Q35 and arm/virt boards Ani Sinha
2026-02-16 8:46 ` Mohamed Mediouni
2026-02-18 9:29 ` Igor Mammedov
2026-02-18 19:10 ` Peter Maydell
2026-02-19 12:27 ` Igor Mammedov
2026-02-19 14:05 ` Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aZ8RByaj4h6i2OXt@redhat.com \
--to=berrange@redhat.com \
--cc=anisinha@redhat.com \
--cc=imammedo@redhat.com \
--cc=leif.lindholm@oss.qualcomm.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=rad@semihalf.com \
--cc=shannon.zhaosl@gmail.com \
--cc=zhao1.liu@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.