Re: [PATCH 0/2] Add support for Gunyah Watchdog

Re: [PATCH 0/2] Add support for Gunyah Watchdog

[Alexander Koskovich]

On 9/4/25 1:05 PM, Pavan Kondeti wrote:
> Thanks for asking this question. I believe the overlay part needs some
> discussion here.
>
> I have tried this series on 8550 MTP. The overlay failed, so watchdog
> device did not probe. same is the case with 8750 too. It works only
> after applying this patch. I will test and report my observation on 8650
> later.

Hi Pavan, was linked this thread after seeing what I think to be the 
same issue on another platform,
but issue is a bit more serious here since bootloader fails to find a 
DTB at all, not just overlay fails.
When the "arch_timer" label is missing from the base DTB on Milos, 
ufdt_apply_overlay in bootloader
will fail and it looks like the DTB memory gets corrupted. If you are 
booting without a dtbo image,
then you don't see the issue. Couple logs from bootloader when it happens:

     ApplyOverlay: ufdt apply overlay failed
     Error: Dtb overlay failed

After this happens, the DTB memory seems to get corrupted:

     ERROR: Invalid device tree header ...
     Device Tree update failed Status:Not Found

But it doesn't seem to have anything to do with the DTBO image itself 
(despite only happening with one),
as it happens even the dtbo is effectively empty with the exception of a 
dummy fixups so the old version
of libufdt in bootloader doesn't fail.

This seems to have only started happening on recent versions of the 
proprietary hypervisor (don't see any
dtb handling in https://github.com/quic/gunyah-hypervisor), since I 
don't see the same issue on Blair but I
do on Milos.

Should the label be applied to all QCOM platforms that have a timer node 
to prevent the issue from appearing
elsewhere? It looks like it's already applied to lemans & sm6150.

Thanks,
Alex

Re: [PATCH 0/2] Add support for Gunyah Watchdog

[Konrad Dybcio]

On 12/22/25 8:02 PM, Alexander Koskovich wrote:
> 
> On 9/4/25 1:05 PM, Pavan Kondeti wrote:
>> Thanks for asking this question. I believe the overlay part needs some
>> discussion here.
>>
>> I have tried this series on 8550 MTP. The overlay failed, so watchdog
>> device did not probe. same is the case with 8750 too. It works only
>> after applying this patch. I will test and report my observation on 8650
>> later.
> 
> Hi Pavan, was linked this thread after seeing what I think to be the 
> same issue on another platform,
> but issue is a bit more serious here since bootloader fails to find a 
> DTB at all, not just overlay fails.
> When the "arch_timer" label is missing from the base DTB on Milos, 
> ufdt_apply_overlay in bootloader
> will fail and it looks like the DTB memory gets corrupted. If you are 
> booting without a dtbo image,
> then you don't see the issue. Couple logs from bootloader when it happens:
> 
>      ApplyOverlay: ufdt apply overlay failed

FWIW this comes from ABL, which is open source

https://git.codelinaro.org/clo/la/abl/tianocore/edk2/

You can probably deduce the correct tag from the boot logs

Konrad

Re: [PATCH 0/2] Add support for Gunyah Watchdog

[Alexander Koskovich]

Hey Konrad,

My device's EDK2 should be on 'KERNEL.PLATFORM.3.0.r1-12700-kernel.0', unfortunately the device I'm working with is secure boot on so I can't modify bootloader to resolve this issue, though I'm not really sure why it's happening when I looked at BootLinux. It seems the hyp dtb handling is the same in both the "dtbo img valid" and "dtbo img invalid" cases, so not sure how it's only happening in the latter case.

Note, that I do have a blair secure boot off device that I flashed with  the same tag (KERNEL.PLATFORM.3.0.r1-12700-kernel.0) since I noticed it happened to support the chipset, but was unable to reproduce the issue there, DTBO gets applied even with a basically empty base DTB. Guessing it may be due to some change in hyp with recent SoCs.

Alex

On Tuesday, December 23rd, 2025 at 12:50 PM, Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> wrote:

>
>
> On 12/22/25 8:02 PM, Alexander Koskovich wrote:
>
> > On 9/4/25 1:05 PM, Pavan Kondeti wrote:
> >
> > > Thanks for asking this question. I believe the overlay part needs some
> > > discussion here.
> > >
> > > I have tried this series on 8550 MTP. The overlay failed, so watchdog
> > > device did not probe. same is the case with 8750 too. It works only
> > > after applying this patch. I will test and report my observation on 8650
> > > later.
> >
> > Hi Pavan, was linked this thread after seeing what I think to be the
> > same issue on another platform,
> > but issue is a bit more serious here since bootloader fails to find a
> > DTB at all, not just overlay fails.
> > When the "arch_timer" label is missing from the base DTB on Milos,
> > ufdt_apply_overlay in bootloader
> > will fail and it looks like the DTB memory gets corrupted. If you are
> > booting without a dtbo image,
> > then you don't see the issue. Couple logs from bootloader when it happens:
> >
> > ApplyOverlay: ufdt apply overlay failed
>
>
> FWIW this comes from ABL, which is open source
>
> https://git.codelinaro.org/clo/la/abl/tianocore/edk2/
>
> You can probably deduce the correct tag from the boot logs
>
> Konrad

Re: [PATCH 0/2] Add support for Gunyah Watchdog

[Konrad Dybcio]

On 1/6/26 2:29 AM, Alexander Koskovich wrote:
> Hey Konrad,
> 
> My device's EDK2 should be on 'KERNEL.PLATFORM.3.0.r1-12700-kernel.0', unfortunately the device I'm working with is secure boot on so I can't modify bootloader to resolve this issue, though I'm not really sure why it's happening when I looked at BootLinux. It seems the hyp dtb handling is the same in both the "dtbo img valid" and "dtbo img invalid" cases, so not sure how it's only happening in the latter case.
> 
> Note, that I do have a blair secure boot off device that I flashed with  the same tag (KERNEL.PLATFORM.3.0.r1-12700-kernel.0) since I noticed it happened to support the chipset, but was unable to reproduce the issue there, DTBO gets applied even with a basically empty base DTB. Guessing it may be due to some change in hyp with recent SoCs.

What I had in mind is that with the sources you can track down where
the issue comes from with a fair degree of confidence.. if that's a
Fairphone-specific issue, maybe you could prettyplease ask these folks
for a BL update somewhere down the line

If you still come to a conclusion that the hyp is wrong, we can accept
that workaround..

Konrad

Re: [PATCH 0/2] Add support for Gunyah Watchdog

[Alexander Koskovich]

On Tuesday, January 13th, 2026 at 9:50 AM, Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> wrote:

> What I had in mind is that with the sources you can track down where
> the issue comes from with a fair degree of confidence.. if that's a
> Fairphone-specific issue, maybe you could prettyplease ask these folks
> for a BL update somewhere down the line
> 
> If you still come to a conclusion that the hyp is wrong, we can accept
> that workaround..

To clarify the device I'm seeing the issue on is the Nothing Phone 3a which is another milos device.

Not sure if this affects the FP6 as well but issue was also seen on an 8550 platform, so seems to have the potential to affect anything 8550+ at least:
https://gitlab.incom.co/cm-ayn/android_kernel_ayn_kernel/-/commit/7ae6565108654991aaac9b73a2221509511e59d3

It's not that I think hyp is wrong, what I'm guessing is it's a bug in bootloader exposed by a change in hyp dtb (since it doesn't affect blair on same abl tag). If that's the case is it still acceptable to workaround?

For the majority of devices on the market you can't really update bootloader, it's signed by the OEM and sending a support ticket about it probably won't go anywhere since it doesn't affect downstream (since it has the label).

Thanks,
Alex

Re: [PATCH 0/2] Add support for Gunyah Watchdog

[Mukesh Ojha]

On Tue, Jan 13, 2026 at 03:07:20PM +0000, Alexander Koskovich wrote:
> On Tuesday, January 13th, 2026 at 9:50 AM, Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> wrote:
> 
> > What I had in mind is that with the sources you can track down where
> > the issue comes from with a fair degree of confidence.. if that's a
> > Fairphone-specific issue, maybe you could prettyplease ask these folks
> > for a BL update somewhere down the line
> > 
> > If you still come to a conclusion that the hyp is wrong, we can accept
> > that workaround..
> 
> To clarify the device I'm seeing the issue on is the Nothing Phone 3a which is another milos device.
> 
> Not sure if this affects the FP6 as well but issue was also seen on an 8550 platform, so seems to have the potential to affect anything 8550+ at least:
> https://gitlab.incom.co/cm-ayn/android_kernel_ayn_kernel/-/commit/7ae6565108654991aaac9b73a2221509511e59d3
> 
> It's not that I think hyp is wrong, what I'm guessing is it's a bug in bootloader exposed by a change in hyp dtb (since it doesn't affect blair on same abl tag). If that's the case is it still acceptable to workaround?

Are you trying to modify hyp dtb here ? how ?

blair is very old SoC and may not be running with Gunyah at all.

> 
> For the majority of devices on the market you can't really update bootloader, it's signed by the OEM and sending a support ticket about it probably won't go anywhere since it doesn't affect downstream (since it has the label).
> 
> Thanks,
> Alex

-- 
-Mukesh Ojha

Re: [PATCH 0/2] Add support for Gunyah Watchdog

[Alexander Koskovich]

On Tuesday, January 13th, 2026 at 10:59 AM, Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> wrote:

> Are you trying to modify hyp dtb here ? how ?
> 
> blair is very old SoC and may not be running with Gunyah at all.

No, don't have the means to modify hyp dtb. Was just guessing at reasons why this issue occurs.

Was just using blair since it's the only secure boot off platform I had on hand so only one I could flash ABL on, but if it's using a different hypervisor than not really a relevant test then.

Alex

Re: [PATCH 0/2] Add support for Gunyah Watchdog

[Mukesh Ojha]

On Tue, Jan 13, 2026 at 04:09:13PM +0000, Alexander Koskovich wrote:
> On Tuesday, January 13th, 2026 at 10:59 AM, Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> wrote:
> 
> > Are you trying to modify hyp dtb here ? how ?
> > 
> > blair is very old SoC and may not be running with Gunyah at all.
> 
> No, don't have the means to modify hyp dtb. Was just guessing at reasons why this issue occurs.
> 
> Was just using blair since it's the only secure boot off platform I had on hand so only one I could flash ABL on, but if it's using a different hypervisor than not really a relevant test then.
> 

Just to clarify you said, there is no issue if you just use dtb and not use dtbo ?
And issue happen when you start using a dtbo, even a dummy one, right ?

-Mukesh

> Alex

-- 
-Mukesh Ojha

Re: [PATCH 0/2] Add support for Gunyah Watchdog

[Alexander Koskovich]

On Tuesday, January 13th, 2026 at 11:47 AM, Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> wrote:

> Just to clarify you said, there is no issue if you just use dtb and not use dtbo ?
> And issue happen when you start using a dtbo, even a dummy one, right ?

Yeah, the cases are as follows:

dtb only (no arch_timer label) = boots
dtb (no arch_timer label) + dtbo = fails
dtb (has arch_timer label) + dtbo = boots

Alex

Re: [PATCH 0/2] Add support for Gunyah Watchdog

[Mukesh Ojha]

On Tue, Jan 13, 2026 at 04:55:56PM +0000, Alexander Koskovich wrote:
> 
> 
> On Tuesday, January 13th, 2026 at 11:47 AM, Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> wrote:
> 
> > Just to clarify you said, there is no issue if you just use dtb and not use dtbo ?
> > And issue happen when you start using a dtbo, even a dummy one, right ?
> 
> Yeah, the cases are as follows:
> 
> dtb only (no arch_timer label) = boots
> dtb (no arch_timer label) + dtbo = fails
> dtb (has arch_timer label) + dtbo = boots

Yes, this is expected..some nodes in dtb is expected which
gets patched during boot up.

https://gitlab.incom.co/cm-ayn/android_kernel_ayn_kernel/-/commit/7ae6565108654991aaac9b73a2221509511e59d3

One of the reason, you will see below change to fix one of the expected
name qcom_scm in the downstream.

https://lore.kernel.org/lkml/20251217-multi_waitq_scm-v11-1-f21e50e792b8@oss.qualcomm.com/

> 
> Alex

-- 
-Mukesh Ojha

[PATCH 0/2] Add support for Gunyah Watchdog

[Hrishabh Rajput via B4 Relay]

Gunyah is a Type-I hypervisor which was introduced in the patch series
[1]. It is an open source hypervisor. The source repo is available at
[2].

The Gunyah Hypervisor doesn't allow its Virtual Machines to directly
access the MMIO watchdog. It either provides the fully emulated MMIO
based watchdog interface or the SMC-based watchdog interface depending
on the hypervisor configuration.
The SMC-based watchdog follows ARM's SMC Calling Convention (SMCCC)
version 1.1 and uses Vendor Specific Hypervisor Service Calls space.

This patch series adds support for the SMC-based watchdog interface
provided by the Gunyah Hypervisor. The driver supports start/stop
operations, timeout and pretimeout configuration, pretimeout interrupt
handling and system restart via watchdog.

This series is tested on SM8750 platform.

[1]
https://lore.kernel.org/all/20240222-gunyah-v17-0-1e9da6763d38@quicinc.com/

[2]
https://github.com/quic/gunyah-hypervisor

Signed-off-by: Hrishabh Rajput <hrishabh.rajput@oss.qualcomm.com>
---
Hrishabh Rajput (2):
      dt-bindings: Add binding for gunyah watchdog
      watchdog: Add driver for Gunyah Watchdog

 .../bindings/watchdog/qcom,gh-watchdog.yaml        |  76 ++++++
 MAINTAINERS                                        |   3 +
 drivers/watchdog/Kconfig                           |  13 +
 drivers/watchdog/Makefile                          |   1 +
 drivers/watchdog/gunyah_wdt.c                      | 268 +++++++++++++++++++++
 include/linux/gunyah_errno.h                       |  77 ++++++
 6 files changed, 438 insertions(+)
---
base-commit: 038d61fd642278bab63ee8ef722c50d10ab01e8f
change-id: 20250903-gunyah_watchdog-2d2649438e29

Best regards,
-- 
Hrishabh Rajput <hrishabh.rajput@oss.qualcomm.com>

Re: [PATCH 0/2] Add support for Gunyah Watchdog

[Rob Herring]

On Wed, Sep 03, 2025 at 07:33:58PM +0000, Hrishabh Rajput wrote:
> Gunyah is a Type-I hypervisor which was introduced in the patch series
> [1]. It is an open source hypervisor. The source repo is available at
> [2].
> 
> The Gunyah Hypervisor doesn't allow its Virtual Machines to directly
> access the MMIO watchdog. It either provides the fully emulated MMIO
> based watchdog interface or the SMC-based watchdog interface depending
> on the hypervisor configuration.

EFI provides a standard watchdog interface. Why can't you use that?

> The SMC-based watchdog follows ARM's SMC Calling Convention (SMCCC)
> version 1.1 and uses Vendor Specific Hypervisor Service Calls space.

Is a watchdog really a hypervisor service? Couldn't a non-virtualized 
OS want to call a watchdog (in secure mode) as well? But I don't know 
how the SMCCC call space is divided up...

> This patch series adds support for the SMC-based watchdog interface
> provided by the Gunyah Hypervisor. The driver supports start/stop
> operations, timeout and pretimeout configuration, pretimeout interrupt
> handling and system restart via watchdog.

Shouldn't system restart be handled by PSCI?

Why can't you probe by trying to see if watchdog smc call succeeds to 
see if there is a watchdog? Then you don't need DT for it.
 
Rob

Re: [PATCH 0/2] Add support for Gunyah Watchdog

[Konrad Dybcio]

On 9/4/25 2:10 AM, Rob Herring wrote:
> On Wed, Sep 03, 2025 at 07:33:58PM +0000, Hrishabh Rajput wrote:
>> Gunyah is a Type-I hypervisor which was introduced in the patch series
>> [1]. It is an open source hypervisor. The source repo is available at
>> [2].
>>
>> The Gunyah Hypervisor doesn't allow its Virtual Machines to directly
>> access the MMIO watchdog. It either provides the fully emulated MMIO
>> based watchdog interface or the SMC-based watchdog interface depending
>> on the hypervisor configuration.
> 
> EFI provides a standard watchdog interface. Why can't you use that?

The use of UEFI at Qualcomm is not exactly what you would expect..

> 
>> The SMC-based watchdog follows ARM's SMC Calling Convention (SMCCC)
>> version 1.1 and uses Vendor Specific Hypervisor Service Calls space.
> 
> Is a watchdog really a hypervisor service? Couldn't a non-virtualized 
> OS want to call a watchdog (in secure mode) as well? But I don't know 
> how the SMCCC call space is divided up...

Gunyah traps SMC calls and acts on a subset of them, passing others
to TZ

>> This patch series adds support for the SMC-based watchdog interface
>> provided by the Gunyah Hypervisor. The driver supports start/stop
>> operations, timeout and pretimeout configuration, pretimeout interrupt
>> handling and system restart via watchdog.
> 
> Shouldn't system restart be handled by PSCI?

I believe the author is trying to say that the watchdog is not
configurable from Linux at present, and if the platform hangs, there
are some indeterminate default settings in place

> 
> Why can't you probe by trying to see if watchdog smc call succeeds to 
> see if there is a watchdog? Then you don't need DT for it.

There apparently isn't a good way to tell from a running system whether
Gunyah is present, unless you make a smc call (which could in theory be
parsed by something else, say a different hypervisor..), but then this
patch only introduces the watchdog interface, without all the cruft that
would actually let us identify the hypervisor, get its version ID and
perform sanity checks..

I would expect that Gunyah has the necessary provisions to inject its
nodes as necessary, at least I recall there was some talk of it in
early revisions of Elliot's aforementioned patches:

https://lore.kernel.org/all/20220811214107.1074343-4-quic_eberman@quicinc.com/

Konrad

Re: [PATCH 0/2] Add support for Gunyah Watchdog

[Rob Herring]

On Thu, Sep 4, 2025 at 6:31 AM Konrad Dybcio
<konrad.dybcio@oss.qualcomm.com> wrote:
>
> On 9/4/25 2:10 AM, Rob Herring wrote:
> > On Wed, Sep 03, 2025 at 07:33:58PM +0000, Hrishabh Rajput wrote:
> >> Gunyah is a Type-I hypervisor which was introduced in the patch series
> >> [1]. It is an open source hypervisor. The source repo is available at
> >> [2].
> >>
> >> The Gunyah Hypervisor doesn't allow its Virtual Machines to directly
> >> access the MMIO watchdog. It either provides the fully emulated MMIO
> >> based watchdog interface or the SMC-based watchdog interface depending
> >> on the hypervisor configuration.
> >
> > EFI provides a standard watchdog interface. Why can't you use that?
>
> The use of UEFI at Qualcomm is not exactly what you would expect..
>
> >
> >> The SMC-based watchdog follows ARM's SMC Calling Convention (SMCCC)
> >> version 1.1 and uses Vendor Specific Hypervisor Service Calls space.
> >
> > Is a watchdog really a hypervisor service? Couldn't a non-virtualized
> > OS want to call a watchdog (in secure mode) as well? But I don't know
> > how the SMCCC call space is divided up...
>
> Gunyah traps SMC calls and acts on a subset of them, passing others
> to TZ

My question was just whether it's the right call space to use. I would
think hypervisor calls would be things like "vm start" or "vm stop",
not something which in theory could be implemented without a
hypervisor in the middle.

> >> This patch series adds support for the SMC-based watchdog interface
> >> provided by the Gunyah Hypervisor. The driver supports start/stop
> >> operations, timeout and pretimeout configuration, pretimeout interrupt
> >> handling and system restart via watchdog.
> >
> > Shouldn't system restart be handled by PSCI?
>
> I believe the author is trying to say that the watchdog is not
> configurable from Linux at present, and if the platform hangs, there
> are some indeterminate default settings in place
>
> >
> > Why can't you probe by trying to see if watchdog smc call succeeds to
> > see if there is a watchdog? Then you don't need DT for it.
>
> There apparently isn't a good way to tell from a running system whether
> Gunyah is present, unless you make a smc call (which could in theory be
> parsed by something else, say a different hypervisor..), but then this
> patch only introduces the watchdog interface, without all the cruft that
> would actually let us identify the hypervisor, get its version ID and
> perform sanity checks..

IIRC, last time we got just a gunyah node. Now it's that plus a
watchdog. What's next? I'm not really a fan of $soc_vendor hypervisor
interfaces. I doubt anyone else is either. We have all sorts of
standard interfaces already between virtio, vfio, EFI, SCMI, PSCI,
etc. Can we please not abuse DT with $soc_vendor hypervisor devices.

Rob

Re: [PATCH 0/2] Add support for Gunyah Watchdog

[Pavan Kondeti]

On Thu, Sep 04, 2025 at 05:51:24PM -0500, Rob Herring wrote:
> > >
> > > Why can't you probe by trying to see if watchdog smc call succeeds to
> > > see if there is a watchdog? Then you don't need DT for it.
> >
> > There apparently isn't a good way to tell from a running system whether
> > Gunyah is present, unless you make a smc call (which could in theory be
> > parsed by something else, say a different hypervisor..), but then this
> > patch only introduces the watchdog interface, without all the cruft that
> > would actually let us identify the hypervisor, get its version ID and
> > perform sanity checks..
> 
> IIRC, last time we got just a gunyah node. Now it's that plus a
> watchdog. What's next? I'm not really a fan of $soc_vendor hypervisor
> interfaces. I doubt anyone else is either. We have all sorts of
> standard interfaces already between virtio, vfio, EFI, SCMI, PSCI,
> etc. Can we please not abuse DT with $soc_vendor hypervisor devices.
> 

We are trying to make the watchdog work with existing SoCs, so we are
sticking with the existing interfaces. The newer devices will not
necessarily need DT to probe hypervisor interfaces.

To answer your question on why can't you probe watchdog smc call to see
if there is a watchdog. Yes, we can do that. It is just that we won't be
able to support pre-timeout IRQ. This IRQ is optional for watchdog
functionality, so this is something we can explore.

Thanks for the feedbck.

Thanks,
Pavan

Re: [PATCH 0/2] Add support for Gunyah Watchdog

[Konrad Dybcio]

On 9/5/25 2:00 AM, Pavan Kondeti wrote:
> On Thu, Sep 04, 2025 at 05:51:24PM -0500, Rob Herring wrote:
>>>>
>>>> Why can't you probe by trying to see if watchdog smc call succeeds to
>>>> see if there is a watchdog? Then you don't need DT for it.
>>>
>>> There apparently isn't a good way to tell from a running system whether
>>> Gunyah is present, unless you make a smc call (which could in theory be
>>> parsed by something else, say a different hypervisor..), but then this
>>> patch only introduces the watchdog interface, without all the cruft that
>>> would actually let us identify the hypervisor, get its version ID and
>>> perform sanity checks..
>>
>> IIRC, last time we got just a gunyah node. Now it's that plus a
>> watchdog. What's next? I'm not really a fan of $soc_vendor hypervisor
>> interfaces. I doubt anyone else is either. We have all sorts of
>> standard interfaces already between virtio, vfio, EFI, SCMI, PSCI,
>> etc. Can we please not abuse DT with $soc_vendor hypervisor devices.
>>
> 
> We are trying to make the watchdog work with existing SoCs, so we are
> sticking with the existing interfaces. The newer devices will not
> necessarily need DT to probe hypervisor interfaces.
> 
> To answer your question on why can't you probe watchdog smc call to see
> if there is a watchdog. Yes, we can do that. It is just that we won't be
> able to support pre-timeout IRQ. This IRQ is optional for watchdog
> functionality, so this is something we can explore.

FWIW Rob, we moved on to SBSA watchdog on newer Gunyah releases..
Which is not ideal as it's still over MMIO, but there's some
progress

I'm not a fan of including the hypervisor in the picture, but as
Pavan said above, we're trying to squeeze the least amount of hacks
necessary to get the most out of existing platforms (i.e. ones which
will not get newer Gunyah).

Perhaps we could extend the MSM KPSS watchdog driver (which pokes at
the physical watchdog on the SoC and whose DT node represents
"reality") and have it attempt to make the SMC call early during probe,
making way for both physical and virt configurations without additional
dt alterations..

Konrad

Re: [PATCH 0/2] Add support for Gunyah Watchdog

[Pavan Kondeti]

On Fri, Sep 05, 2025 at 12:18:06PM +0200, Konrad Dybcio wrote:
> On 9/5/25 2:00 AM, Pavan Kondeti wrote:
> > On Thu, Sep 04, 2025 at 05:51:24PM -0500, Rob Herring wrote:
> >>>>
> >>>> Why can't you probe by trying to see if watchdog smc call succeeds to
> >>>> see if there is a watchdog? Then you don't need DT for it.
> >>>
> >>> There apparently isn't a good way to tell from a running system whether
> >>> Gunyah is present, unless you make a smc call (which could in theory be
> >>> parsed by something else, say a different hypervisor..), but then this
> >>> patch only introduces the watchdog interface, without all the cruft that
> >>> would actually let us identify the hypervisor, get its version ID and
> >>> perform sanity checks..
> >>
> >> IIRC, last time we got just a gunyah node. Now it's that plus a
> >> watchdog. What's next? I'm not really a fan of $soc_vendor hypervisor
> >> interfaces. I doubt anyone else is either. We have all sorts of
> >> standard interfaces already between virtio, vfio, EFI, SCMI, PSCI,
> >> etc. Can we please not abuse DT with $soc_vendor hypervisor devices.
> >>
> > 
> > We are trying to make the watchdog work with existing SoCs, so we are
> > sticking with the existing interfaces. The newer devices will not
> > necessarily need DT to probe hypervisor interfaces.
> > 
> > To answer your question on why can't you probe watchdog smc call to see
> > if there is a watchdog. Yes, we can do that. It is just that we won't be
> > able to support pre-timeout IRQ. This IRQ is optional for watchdog
> > functionality, so this is something we can explore.
> 
> FWIW Rob, we moved on to SBSA watchdog on newer Gunyah releases..
> Which is not ideal as it's still over MMIO, but there's some
> progress

Gunyah running in Latest SoCs do support SoC watchdog emulation, so
Linux does not need to worry about if it is running under Gunyah or bare
metal.

> 
> I'm not a fan of including the hypervisor in the picture, but as
> Pavan said above, we're trying to squeeze the least amount of hacks
> necessary to get the most out of existing platforms (i.e. ones which
> will not get newer Gunyah).

Thanks for enumerating our goal here. we plan to support watchdog (hence
collecting dumps) on existing platform where Linux has only access to
this SMCC interface.

> 
> Perhaps we could extend the MSM KPSS watchdog driver (which pokes at
> the physical watchdog on the SoC and whose DT node represents
> "reality") and have it attempt to make the SMC call early during probe,
> making way for both physical and virt configurations without additional
> dt alterations..
> 

We have to be careful here. I am told that SMCC interface might not fail
even when Gunyah is emulating SoC watchdog. We can do something like
this.

If we don't find "qcom,kpss-wdt" compatible device, then we can add a
fallback to Gunyah based SMCC.

Thanks,
Pavan

Re: [PATCH 0/2] Add support for Gunyah Watchdog

[Konrad Dybcio]

On 9/8/25 7:49 AM, Pavan Kondeti wrote:
> On Fri, Sep 05, 2025 at 12:18:06PM +0200, Konrad Dybcio wrote:
>> On 9/5/25 2:00 AM, Pavan Kondeti wrote:
>>> On Thu, Sep 04, 2025 at 05:51:24PM -0500, Rob Herring wrote:
>>>>>>
>>>>>> Why can't you probe by trying to see if watchdog smc call succeeds to
>>>>>> see if there is a watchdog? Then you don't need DT for it.
>>>>>
>>>>> There apparently isn't a good way to tell from a running system whether
>>>>> Gunyah is present, unless you make a smc call (which could in theory be
>>>>> parsed by something else, say a different hypervisor..), but then this
>>>>> patch only introduces the watchdog interface, without all the cruft that
>>>>> would actually let us identify the hypervisor, get its version ID and
>>>>> perform sanity checks..
>>>>
>>>> IIRC, last time we got just a gunyah node. Now it's that plus a
>>>> watchdog. What's next? I'm not really a fan of $soc_vendor hypervisor
>>>> interfaces. I doubt anyone else is either. We have all sorts of
>>>> standard interfaces already between virtio, vfio, EFI, SCMI, PSCI,
>>>> etc. Can we please not abuse DT with $soc_vendor hypervisor devices.
>>>>
>>>
>>> We are trying to make the watchdog work with existing SoCs, so we are
>>> sticking with the existing interfaces. The newer devices will not
>>> necessarily need DT to probe hypervisor interfaces.
>>>
>>> To answer your question on why can't you probe watchdog smc call to see
>>> if there is a watchdog. Yes, we can do that. It is just that we won't be
>>> able to support pre-timeout IRQ. This IRQ is optional for watchdog
>>> functionality, so this is something we can explore.
>>
>> FWIW Rob, we moved on to SBSA watchdog on newer Gunyah releases..
>> Which is not ideal as it's still over MMIO, but there's some
>> progress
> 
> Gunyah running in Latest SoCs do support SoC watchdog emulation, so
> Linux does not need to worry about if it is running under Gunyah or bare
> metal.
> 
>>
>> I'm not a fan of including the hypervisor in the picture, but as
>> Pavan said above, we're trying to squeeze the least amount of hacks
>> necessary to get the most out of existing platforms (i.e. ones which
>> will not get newer Gunyah).
> 
> Thanks for enumerating our goal here. we plan to support watchdog (hence
> collecting dumps) on existing platform where Linux has only access to
> this SMCC interface.

I think you didn't explain it clearly - do we need the wdog to bite to
enter crashdump at all on these platforms?

> 
>>
>> Perhaps we could extend the MSM KPSS watchdog driver (which pokes at
>> the physical watchdog on the SoC and whose DT node represents
>> "reality") and have it attempt to make the SMC call early during probe,
>> making way for both physical and virt configurations without additional
>> dt alterations..
>>
> 
> We have to be careful here. I am told that SMCC interface might not fail
> even when Gunyah is emulating SoC watchdog. We can do something like
> this.

"not failling when gunyah is emulating the watchdog" is sort of what we
want, no? Unless you meant that if MMIO access is allowed, the SMC
interface may still report no errors, even though the calls don't
actually end up doing anything useful

> 
> If we don't find "qcom,kpss-wdt" compatible device, then we can add a
> fallback to Gunyah based SMCC.

Matching on "not compatible" is tricky, especially since the arm64
kernel builds must support all platforms at once

Konrad

Re: [PATCH 0/2] Add support for Gunyah Watchdog

[Hrishabh Rajput]

On 9/4/2025 5:40 AM, Rob Herring wrote:
> On Wed, Sep 03, 2025 at 07:33:58PM +0000, Hrishabh Rajput wrote:
>> Gunyah is a Type-I hypervisor which was introduced in the patch series
>> [1]. It is an open source hypervisor. The source repo is available at
>> [2].
>>
>> The Gunyah Hypervisor doesn't allow its Virtual Machines to directly
>> access the MMIO watchdog. It either provides the fully emulated MMIO
>> based watchdog interface or the SMC-based watchdog interface depending
>> on the hypervisor configuration.
> EFI provides a standard watchdog interface. Why can't you use that?

I need to explore about EFI watchdog. But Gunyah Hypervisor does provide 
various interfaces for watchdog including fully emulated watchdog.

There are Qualcomm SoCs in the market that ship with SMC-based watchdog 
interface configuration of the Gunyah Hypervisor. The purpose of this 
patch to add support for that configuration.

>> The SMC-based watchdog follows ARM's SMC Calling Convention (SMCCC)
>> version 1.1 and uses Vendor Specific Hypervisor Service Calls space.
> Is a watchdog really a hypervisor service? Couldn't a non-virtualized
> OS want to call a watchdog (in secure mode) as well? But I don't know
> how the SMCCC call space is divided up...


Sure, a non-virtualized OS could directly access the watchdog. 
Hypervisor needs to interfere when there are multiple virtual machines 
running simultaneously and we only have a single watchdog device.

>> This patch series adds support for the SMC-based watchdog interface
>> provided by the Gunyah Hypervisor. The driver supports start/stop
>> operations, timeout and pretimeout configuration, pretimeout interrupt
>> handling and system restart via watchdog.
> Shouldn't system restart be handled by PSCI?


By "system restart via watchdog" I meant the restart routine in the 
watchdog_ops struct. And I've kept the watchdog restart priority to the 
lowest i.e., 0, so it will be used a last resort.

> Why can't you probe by trying to see if watchdog smc call succeeds to
> see if there is a watchdog? Then you don't need DT for it.
>   
> Rob

We could do that for checking if SMC-based watchdog interface is 
supported, but DT provides an additional information about the 
pretimeout IRQ.

And there is no way to get that information apart from the DT.


Thanks,

Hrishabh

Re: [PATCH 0/2] Add support for Gunyah Watchdog

[Neil Armstrong]

On 03/09/2025 21:33, Hrishabh Rajput via B4 Relay wrote:
> Gunyah is a Type-I hypervisor which was introduced in the patch series
> [1]. It is an open source hypervisor. The source repo is available at
> [2].
> 
> The Gunyah Hypervisor doesn't allow its Virtual Machines to directly
> access the MMIO watchdog. It either provides the fully emulated MMIO
> based watchdog interface or the SMC-based watchdog interface depending
> on the hypervisor configuration.
> The SMC-based watchdog follows ARM's SMC Calling Convention (SMCCC)
> version 1.1 and uses Vendor Specific Hypervisor Service Calls space.
> 
> This patch series adds support for the SMC-based watchdog interface
> provided by the Gunyah Hypervisor. The driver supports start/stop
> operations, timeout and pretimeout configuration, pretimeout interrupt
> handling and system restart via watchdog.
> 
> This series is tested on SM8750 platform.

Would this driver work on older platforms like SM8550 & SM8650 ?

Thanks,
Neil

> 
> [1]
> https://lore.kernel.org/all/20240222-gunyah-v17-0-1e9da6763d38@quicinc.com/
> 
> [2]
> https://github.com/quic/gunyah-hypervisor
> 
> Signed-off-by: Hrishabh Rajput <hrishabh.rajput@oss.qualcomm.com>
> ---
> Hrishabh Rajput (2):
>        dt-bindings: Add binding for gunyah watchdog
>        watchdog: Add driver for Gunyah Watchdog
> 
>   .../bindings/watchdog/qcom,gh-watchdog.yaml        |  76 ++++++
>   MAINTAINERS                                        |   3 +
>   drivers/watchdog/Kconfig                           |  13 +
>   drivers/watchdog/Makefile                          |   1 +
>   drivers/watchdog/gunyah_wdt.c                      | 268 +++++++++++++++++++++
>   include/linux/gunyah_errno.h                       |  77 ++++++
>   6 files changed, 438 insertions(+)
> ---
> base-commit: 038d61fd642278bab63ee8ef722c50d10ab01e8f
> change-id: 20250903-gunyah_watchdog-2d2649438e29
> 
> Best regards,

Re: [PATCH 0/2] Add support for Gunyah Watchdog

[Pavan Kondeti]

On Thu, Sep 04, 2025 at 09:13:23AM +0200, Neil Armstrong wrote:
> On 03/09/2025 21:33, Hrishabh Rajput via B4 Relay wrote:
> > Gunyah is a Type-I hypervisor which was introduced in the patch series
> > [1]. It is an open source hypervisor. The source repo is available at
> > [2].
> > 
> > The Gunyah Hypervisor doesn't allow its Virtual Machines to directly
> > access the MMIO watchdog. It either provides the fully emulated MMIO
> > based watchdog interface or the SMC-based watchdog interface depending
> > on the hypervisor configuration.
> > The SMC-based watchdog follows ARM's SMC Calling Convention (SMCCC)
> > version 1.1 and uses Vendor Specific Hypervisor Service Calls space.
> > 
> > This patch series adds support for the SMC-based watchdog interface
> > provided by the Gunyah Hypervisor. The driver supports start/stop
> > operations, timeout and pretimeout configuration, pretimeout interrupt
> > handling and system restart via watchdog.
> > 
> > This series is tested on SM8750 platform.
> 
> Would this driver work on older platforms like SM8550 & SM8650 ?
> 

This driver should work on 8550 and 8650 too as long as the hypervisor
overlay is applied to the device tree which happens in the bootloader.

I remember porting some hypercalls to 8550 upstream kernel to induce the
watchdog bite in panic to collect the dumps. one of the biggest benefit
w/ this driver is that we can collect dumps upon kernel panic. since we
won't be able to pet the watchdog upon panic, the bite would eventually
happens and device enters dump collection mode.

Thanks,
Pavan

Re: [PATCH 0/2] Add support for Gunyah Watchdog

[Bjorn Andersson]

On Thu, Sep 04, 2025 at 02:48:03PM +0530, Pavan Kondeti wrote:
> On Thu, Sep 04, 2025 at 09:13:23AM +0200, Neil Armstrong wrote:
> > On 03/09/2025 21:33, Hrishabh Rajput via B4 Relay wrote:
> > > Gunyah is a Type-I hypervisor which was introduced in the patch series
> > > [1]. It is an open source hypervisor. The source repo is available at
> > > [2].
> > > 
> > > The Gunyah Hypervisor doesn't allow its Virtual Machines to directly
> > > access the MMIO watchdog. It either provides the fully emulated MMIO
> > > based watchdog interface or the SMC-based watchdog interface depending
> > > on the hypervisor configuration.
> > > The SMC-based watchdog follows ARM's SMC Calling Convention (SMCCC)
> > > version 1.1 and uses Vendor Specific Hypervisor Service Calls space.
> > > 
> > > This patch series adds support for the SMC-based watchdog interface
> > > provided by the Gunyah Hypervisor. The driver supports start/stop
> > > operations, timeout and pretimeout configuration, pretimeout interrupt
> > > handling and system restart via watchdog.
> > > 
> > > This series is tested on SM8750 platform.
> > 
> > Would this driver work on older platforms like SM8550 & SM8650 ?
> > 
> 
> This driver should work on 8550 and 8650 too as long as the hypervisor
> overlay is applied to the device tree which happens in the bootloader.
> 

You have easy access to 8550 and 8650 MTP/QRD devices, please give us a
definitive answer.

Regards,
Bjorn

> I remember porting some hypercalls to 8550 upstream kernel to induce the
> watchdog bite in panic to collect the dumps. one of the biggest benefit
> w/ this driver is that we can collect dumps upon kernel panic. since we
> won't be able to pet the watchdog upon panic, the bite would eventually
> happens and device enters dump collection mode.
> 
> Thanks,
> Pavan

Re: [PATCH 0/2] Add support for Gunyah Watchdog

[Pavan Kondeti]

On Thu, Sep 04, 2025 at 08:53:14AM -0500, Bjorn Andersson wrote:
> On Thu, Sep 04, 2025 at 02:48:03PM +0530, Pavan Kondeti wrote:
> > On Thu, Sep 04, 2025 at 09:13:23AM +0200, Neil Armstrong wrote:
> > > On 03/09/2025 21:33, Hrishabh Rajput via B4 Relay wrote:
> > > > Gunyah is a Type-I hypervisor which was introduced in the patch series
> > > > [1]. It is an open source hypervisor. The source repo is available at
> > > > [2].
> > > > 
> > > > The Gunyah Hypervisor doesn't allow its Virtual Machines to directly
> > > > access the MMIO watchdog. It either provides the fully emulated MMIO
> > > > based watchdog interface or the SMC-based watchdog interface depending
> > > > on the hypervisor configuration.
> > > > The SMC-based watchdog follows ARM's SMC Calling Convention (SMCCC)
> > > > version 1.1 and uses Vendor Specific Hypervisor Service Calls space.
> > > > 
> > > > This patch series adds support for the SMC-based watchdog interface
> > > > provided by the Gunyah Hypervisor. The driver supports start/stop
> > > > operations, timeout and pretimeout configuration, pretimeout interrupt
> > > > handling and system restart via watchdog.
> > > > 
> > > > This series is tested on SM8750 platform.
> > > 
> > > Would this driver work on older platforms like SM8550 & SM8650 ?
> > > 
> > 
> > This driver should work on 8550 and 8650 too as long as the hypervisor
> > overlay is applied to the device tree which happens in the bootloader.
> > 
> 
> You have easy access to 8550 and 8650 MTP/QRD devices, please give us a
> definitive answer.
> 

Thanks for asking this question. I believe the overlay part needs some
discussion here.

I have tried this series on 8550 MTP. The overlay failed, so watchdog
device did not probe. same is the case with 8750 too. It works only
after applying this patch. I will test and report my observation on 8650
later.

diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 140b0b2abfb5..b200e8faa6df 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -1,4 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
+DTC_FLAGS := -@
 dtb-$(CONFIG_ARCH_QCOM)	+= apq8016-sbc.dtb
 
 apq8016-sbc-usb-host-dtbs	:= apq8016-sbc.dtb apq8016-sbc-usb-host.dtbo
diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
index eac8de4005d8..7536b1a4ec97 100644
--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
@@ -328,7 +328,7 @@ cluster_sleep_1: cluster-sleep-1 {
 	};
 
 	firmware {
-		scm: scm {
+		scm: qcom_scm {
 			compatible = "qcom,scm-sm8550", "qcom,scm";
 			qcom,dload-mode = <&tcsr 0x19000>;
 			interconnects = <&aggre2_noc MASTER_CRYPTO 0 &mc_virt SLAVE_EBI1 0>;
@@ -4855,6 +4855,9 @@ compute-cb@8 {
 				};
 			};
 		};
+
+		qcom_tzlog: tz-log {
+		};
 	};
 
 	thermal-zones {
@@ -5913,7 +5916,7 @@ trip-point2 {
 		};
 	};
 
-	timer {
+	arch_timer: timer {
 		compatible = "arm,armv8-timer";
 		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
 			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,


Thanks,
Pavan