Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1222422 > unrolled thread

Re: [PATCH v7 5/8] Watchdog: introduce ARM SBSA watchdog driver

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v7 5/8] Watchdog: introduce ARM SBSA watchdog driver Jon Masters <jcm@redhat.com> - 2015-09-11 00:40 +0200
    Re: [PATCH v7 5/8] Watchdog: introduce ARM SBSA watchdog driver Guenter Roeck <linux@roeck-us.net> - 2015-09-11 04:10 +0200
    Re: [PATCH v7 5/8] Watchdog: introduce ARM SBSA watchdog driver Guenter Roeck <linux@roeck-us.net> - 2015-09-11 05:00 +0200
      Re: [PATCH v7 5/8] Watchdog: introduce ARM SBSA watchdog driver Fu Wei <fu.wei@linaro.org> - 2015-09-14 19:20 +0200

#1222422 — Re: [PATCH v7 5/8] Watchdog: introduce ARM SBSA watchdog driver

On 08/24/2015 01:01 PM, fu.wei@linaro.org wrote:

> +	/*
> +	 * Get the frequency of system counter from the cp15 interface of ARM
> +	 * Generic timer. We don't need to check it, because if it returns "0",
> +	 * system would panic in very early stage.
> +	 */
> +	gwdt->clk = arch_timer_get_cntfrq();

Just thinking out loud...

What happens later if we virtualize this device within KVM/QEMU/Xen and
then live migrate to another system in which the frequency changes?

Jon.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1222485

On Thu, Sep 10, 2015 at 06:29:53PM -0400, Jon Masters wrote:
> On 08/24/2015 01:01 PM, fu.wei@linaro.org wrote:
> 
> > +	/*
> > +	 * Get the frequency of system counter from the cp15 interface of ARM
> > +	 * Generic timer. We don't need to check it, because if it returns "0",
> > +	 * system would panic in very early stage.
> > +	 */
> > +	gwdt->clk = arch_timer_get_cntfrq();
> 
> Just thinking out loud...
> 
> What happens later if we virtualize this device within KVM/QEMU/Xen and
> then live migrate to another system in which the frequency changes?
> 
I don't know, but I would suspect that we might end up in all kinds of
trouble if clocks can change like that, and not just in this driver.
Many drivers make the assumption that clock rates are not changed
under the hood. If it can happen, shouldn't there be a callback into
the drivers using the affected clock(s) ?

Also, it seems to me that changing a clock like that would be inherently
unsafe. For example, what will happen if the system is stopped and migrated
right after the clock frequency is read, but before the returned value
is used ? Can that happen ? Or does it only happen during suspend/resume
cycles, if it happens ?

Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222501

On 09/10/2015 03:29 PM, Jon Masters wrote:
> On 08/24/2015 01:01 PM, fu.wei@linaro.org wrote:
>
>> +	/*
>> +	 * Get the frequency of system counter from the cp15 interface of ARM
>> +	 * Generic timer. We don't need to check it, because if it returns "0",
>> +	 * system would panic in very early stage.
>> +	 */
>> +	gwdt->clk = arch_timer_get_cntfrq();
>
> Just thinking out loud...
>
> What happens later if we virtualize this device within KVM/QEMU/Xen and
> then live migrate to another system in which the frequency changes?
>

Thinking about it, this scenario would cause severe trouble. I think clocks
(like I would assume pretty much all other hardware parameters / registers)
need to be virtualized and must not change.

Example: clock is set to 100 kHz on original system, and 400 kHz on new
system. Timeout is set to 30s, and registers are programmed accordingly.
User space sends heartbeats every 15 seconds.

In this scenario, the watchdog would time out after 30/4 = 7.5 seconds
on the new system, or in other words almost immediately.

This would be even worse if the original system had a clock of, say,
10 kHz and the new system would use 400 kHz. This just doesn't work.

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1224353

Hi Guenter, Jon,

On 11 September 2015 at 10:50, Guenter Roeck <linux@roeck-us.net> wrote:
> On 09/10/2015 03:29 PM, Jon Masters wrote:
>>
>> On 08/24/2015 01:01 PM, fu.wei@linaro.org wrote:
>>
>>> +       /*
>>> +        * Get the frequency of system counter from the cp15 interface of
>>> ARM
>>> +        * Generic timer. We don't need to check it, because if it
>>> returns "0",
>>> +        * system would panic in very early stage.
>>> +        */
>>> +       gwdt->clk = arch_timer_get_cntfrq();
>>
>>
>> Just thinking out loud...
>>
>> What happens later if we virtualize this device within KVM/QEMU/Xen and
>> then live migrate to another system in which the frequency changes?
>>
>
> Thinking about it, this scenario would cause severe trouble. I think clocks
> (like I would assume pretty much all other hardware parameters / registers)
> need to be virtualized and must not change.
>
> Example: clock is set to 100 kHz on original system, and 400 kHz on new
> system. Timeout is set to 30s, and registers are programmed accordingly.
> User space sends heartbeats every 15 seconds.
>
> In this scenario, the watchdog would time out after 30/4 = 7.5 seconds
> on the new system, or in other words almost immediately.
>
> This would be even worse if the original system had a clock of, say,
> 10 kHz and the new system would use 400 kHz. This just doesn't work.

I have rechecked the SBSA spec and "Architecture Reference Manual(ARM)",
I think we don't need to worry about "the frequency changes", let me
explain this, but if I misunderstand something, please correct me!

(1) what is the clock source (or reference) of SBSA watchdog timer?
SBSA spec(2.3) has answered this well at page 23:
---------------------------
The Watchdog uses the Generic Timer system count value as the timebase
against which the decision to trigger an interrupt is made.
---------------------------

(2) Can the frequency of the Generic Timer System counter be changed?
At ARMv8 ARM,  D6.1.1 System counter :
---------------------------
The Generic Timer provides a system counter with the following specification:
Frequency
Increments at *a fixed frequency*, typically in the range 1-50MHz.
Can support one or more alternative operating modes in which it
increments by larger amounts at a lower frequency, typically for
power-saving.

To support lower-power operating modes, the counter can increment by
larger amounts at a lower frequency. For example, a 10MHz system
counter might either increment either:
• By 1 at 10MHz.
• By 500 at 20kHz,
when the system lowers the clock frequency, to reduce power consumption.
In this case, the counter must support transitions between
high-frequency, high-precision operation, and lower-frequency,
lower-precision operation, without any impact on the required accuracy
of the counter.
---------------------------
So even the frequency of the Generic Timer System counter be changed
by some reason(typically for power-saving), this won't affect the
timeout(and pretimeout) of watchdog, the actual time will be always
right.

*we were talking about real hardware above. Now we think about virtualization.*
(3) if the virtual watchdog device in KVM/QEMU/Xen is migrated to
another system in which the frequency changes, will it affect the "dog
feeding procedure"?

I don't think so.
if the frequency changes, the frequency of System counter is changed.
But in ARM system, System counter is a global reference for all clocks
or timers(per-cpu and Memory-mapped).
So if   System counter is getting faster, everything in this  virtual
machine is getting faster, and vice versa.

Now we use the example above
if  clock is set to 100 kHz on original system, and 400 kHz on new system.
Timeout is set to 30s, and registers are programmed accordingly. User
space sends heartbeats every 15 seconds.
In this scenario, On the new system, the watchdog would time out after
30/4 = 7.5 seconds.
* User space sends heartbeats every 15/4 = 3.25 second now , but NOT
15 seconds.*
If everything goes well,  system will keep running.

Hope I understand the question correctly, please  correct me if I miss
something or said anything wrong.

Great thanks for your feedback!

>
> Guenter
>



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web