If the effective watchdog tick frequency is platform specific then it is my opinion that the only thing that should be specified as parameters for the watchdog block is its tick frequency. Why complicate it with an assumption of the backing clock when all that matters is the effective watchdog frequency. Guidance is already provided w.r.t. expectations. I suggest we simplify the spec. Existing implementations can provide their own determinism of the frequency by exposing some bit and mtime frequency, but that does not need to be true for all implementations.

There's a 'timeout counter' term being used. Is the intention that this timeout counter value actually be hidden? i.e. there's no way to read the timeout counter itself? If so, why is this timeout counter not a part of the register set?

On Thu, Oct 7, 2021 at 7:34 PM Aaron Durbin <adurbin@...> wrote:

If the effective watchdog tick frequency is platform specific then it is my opinion that the only thing that should be specified as parameters for the watchdog block is its tick frequency. Why complicate it with an assumption of the backing clock when all that matters is the effective watchdog frequency. Guidance is already provided w.r.t. expectations. I suggest we simplify the spec. Existing implementations can provide their own determinism of the frequency by exposing some bit and mtime frequency, but that does not need to be true for all implementations.

I agree that all that needs to be discoverable is the watchdog tick period or frequency.  Further, if a platform spec requires a specific frequency, then even that doesn't need to be discoverable.

 

There's a 'timeout counter' term being used. Is the intention that this timeout counter value actually be hidden? i.e. there's no way to read the timeout counter itself? If so, why is this timeout counter not a part of the register set?

There is no specific intention to hide the timeout counter.  There just hasgn't appeared to be a justifiable need yet to support reading of it.

Greg

 

Apologies for the delay in response, I am traveling currently.

 

From: <tech-unixplatformspec@...> on behalf of Aaron Durbin <adurbin@...>
Date: Friday, 8 October 2021 at 8:04 AM
To: "tech-unixplatformspec@..." <tech-unixplatformspec@...>
Subject: [RISC-V] [tech-unixplatformspec] Watchdog Spec Questions

 

Hi,

 

I have some questions related to the Watchdog spec found here: https://github.com/riscv-non-isa/riscv-watchdog/blob/main/riscv-watchdog.adoc

 

1. The spec goes to great lengths to describe the watchdog tick frequency in terms of MTIME frequency and a bit position within MTIME serving as a divider. However:

 

"The choice of MTIME resolution and MTIME bit position for watchdog tick is platform specific and these parameters should be discoverable by software via platform-specific means. It is recommended that these parameters are chosen so as to provide a watchdog tick resolution between 0.1 sec and 1 sec, ensuring a maximum timeout period (WTOCNT=0x3FF) greater than 100 seconds."

 

If the effective watchdog tick frequency is platform specific then it is my opinion that the only thing that should be specified as parameters for the watchdog block is its tick frequency. Why complicate it with an assumption of the backing clock when all that matters is the effective watchdog frequency. Guidance is already provided w.r.t. expectations. I suggest we simplify the spec. Existing implementations can provide their own determinism of the frequency by exposing some bit and mtime frequency, but that does not need to be true for all implementations.

 

[Anup] The MTIME frequency is already available to software (via DT or ACPI) so software only needs to know the MTIME bit position used for watchdog tick. This means we can either provide MTIME bit position OR effective watchdog tick frequency in DT or ACPI. We choose MTIME bit position to be available in DT or ACPI because:

1. It describes the watchdog HW better compared to having software derive MTIME bit position from effective watchdog tick frequency.
2. Knowing the MTIME bit position also helps software do adjustments in WTOCNT value because the first watchdog tick is mostly a partial tick since MTIME is a free running counter independent of watchdog timeout counter.

 

2. We have the following statements w.r.t. WTOCNT:

 

"The 10-bit WTOCNT value initializes a 10-bit timeout counter."

 

"If timeout counter is now zero then

    if S1WTO=1 then set S2WTO
    else set S1WTO and re-initialize the timeout counter with WTOCNT"

 

There's a 'timeout counter' term being used. Is the intention that this timeout counter value actually be hidden? i.e. there's no way to read the timeout counter itself? If so, why is this timeout counter not a part of the register set?

 

[Anup] We did not see any use-case for exposing “timeout counter” as separate registers from Linux watchdog framework perspective. If it is useful then we can certainly add read-only “timeout counter” register.

 

Regards,

Anup

 

Thanks.

 

-Aaron

 

There is no specific intention to hide the timeout counter.  There just hasgn't appeared to be a justifiable need yet to support reading of it.

I think it's informative in that one can read the current timeout counter value and observe it tick. That has been useful in the past from my experience.

I don't think doing trap-and-emulate to handle reads of the watchdog timer would be much of a problem for a hypervisor. That functionality would be needed for emulating almost any other common device. To be somewhat flippant, if someone is thinking of emulating this watchdog timer and it is anywhere close to the most complex device they're emulating, then something is probably going seriously wrong.

I am missing why M-mode needs to trap and emulate a virtual watchdog
device access from a guest OS. That should be a hypervisor function.

A hypervisor that passes through a virtual watchdog device to its guest
has to trap and emulate the virtual watchdog device anyway - including
having a virtual watchdog timer that is emulated by the hypervisor.

Is it intended/required that S1WTO and S2WTO be literal interrupts?  In particular, it might be desirable for S2WTO to actually be an NMI or reset to recover a system that is not healthy enough to handle the S1WTO.

The watchdog spec does not provide a means to configure an MSI
destination for the S1WTO. Is that planned/discussed?

Even the first-stage timeout would probably be more useful to the OS if it was a "non-maskable interrupt" or otherwise able to arrive even with sstatus.SIE bit unset.

If the system has locked up to the point that the watchdog timer is expiring, that probably means that normal timer interrupts aren't arriving to the OS. And that could be caused either by stimecmp being unset/configured wrong (unlikely) or because the OS has interrupts disabled and is either blocking or entered an infinite loop.