Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Sun, 08 Aug 2021 11:29:52 +0100
Message-ID: <87mtps1b6n.wl-maz@kernel.org>
From:   Marc Zyngier <maz@kernel.org>
To:     Linus Walleij <linus.walleij@linaro.org>
Cc:     Oliver Upton <oupton@google.com>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Daniel Lezcano <daniel.lezcano@linaro.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Peter Shier <pshier@google.com>,
        Raghavendra Rao Ananta <rananta@google.com>,
        Ricardo Koller <ricarkol@google.com>
Subject: Re: [PATCH v2] clocksource/arm_arch_timer: Fix masking for high freq counters
In-Reply-To: <CACRpkdYPEGygxAtU8jrCtnJsQr_JoYkBCRGpRFpvxGiOzUmxgg@mail.gmail.com>
References: <20210807191428.3488948-1-oupton@google.com>
        <CACRpkdYPEGygxAtU8jrCtnJsQr_JoYkBCRGpRFpvxGiOzUmxgg@mail.gmail.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue)
 FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1
 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

On Sat, 07 Aug 2021 23:30:20 +0100,
Linus Walleij <linus.walleij@linaro.org> wrote:
> 
> On Sat, Aug 7, 2021 at 9:14 PM Oliver Upton <oupton@google.com> wrote:
> 
> > Unfortunately, the architecture provides no means to determine the bit
> > width of the system counter. However, we do know the following from the
> > specification:
> >
> >  - the system counter is at least 56 bits wide
> >  - Roll-over time of not less than 40 years
> >
> > To date, the arch timer driver has depended on the first property,
> > assuming any system counter to be 56 bits wide and masking off the rest.
> > However, combining a narrow clocksource mask with a high frequency
> > counter could result in prematurely wrapping the system counter by a
> > significant margin. For example, a 56 bit wide, 1GHz system counter
> > would wrap in a mere 2.28 years!
> >
> > This is a problem for two reasons: v8.6+ implementations are required to
> > provide a 64 bit, 1GHz system counter. Furthermore, before v8.6,
> > implementers may select a counter frequency of their choosing.
> >
> > Fix the issue by deriving a valid clock mask based on the second
> > property from above. Set the floor at 56 bits, since we know no system
> > counter is narrower than that.
> >
> > Suggested-by: Marc Zyngier <maz@kernel.org>
> > Signed-off-by: Oliver Upton <oupton@google.com>
> 
> This patch looks good to me:
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> 
> Just a thought that crossed my mind: as this is real hardware we are
> talking about mostly, how hard would it be for arch_counter_get_width()
> to detect how wide it actually is if nbits > 56?
> 
> I would do something like this pseudocode:
> 
> nbits = 56;
> while (nbits < 64)
>     startval = GENMASK(nbits, 0);
>     write_counter(startval);

That's where things stop. The counter is not writable, and for good
reasons (it is shared with all the CPUs in the system).

>     start_counter;
>     nsleep(1);
>     stop_counter;
>     now = read_counter;
>     if (now < startval)
>          /* Ooops it wrapped */
>          break;
>     nbits++
> 
> pr_info("counter has %d bits\n", nbits);
> 
> Or did you folks already try this approach?

The only way to emulate this behaviour is to use CNTVOFF_EL2 at EL2 to
offset a guest view of the counter, and to run minimal guest that will
do the start/stop/compare work. Given that it involves running a guest
at a point where we are unable to do so, and that it cannot work when
booted at EL1, we're left with guesswork.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.