linux-kernel - Re: [PATCH 09/13] KVM: arm64: Add clock for hyp tracefs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANDhNCqvwn7W8JgdzY=2PrEk0unm3E0Kso7h2CCZBPO+hzLaOw@mail.gmail.com>
Date: Fri, 13 Sep 2024 16:21:05 -0700
From: John Stultz <jstultz@...gle.com>
To: Vincent Donnefort <vdonnefort@...gle.com>
Cc: rostedt@...dmis.org, mhiramat@...nel.org, 
	linux-trace-kernel@...r.kernel.org, maz@...nel.org, oliver.upton@...ux.dev, 
	kvmarm@...ts.linux.dev, will@...nel.org, qperret@...gle.com, 
	kernel-team@...roid.com, linux-kernel@...r.kernel.org, 
	Thomas Gleixner <tglx@...utronix.de>, Stephen Boyd <sboyd@...nel.org>, 
	"Christopher S. Hall" <christopher.s.hall@...el.com>, Richard Cochran <richardcochran@...il.com>, 
	Lakshmi Sowjanya D <lakshmi.sowjanya.d@...el.com>
Subject: Re: [PATCH 09/13] KVM: arm64: Add clock for hyp tracefs

On Wed, Sep 11, 2024 at 2:31 AM Vincent Donnefort <vdonnefort@...gle.com> wrote:
>
> Configure the hypervisor tracing clock before starting tracing. For
> tracing purpose, the boot clock is interesting as it doesn't stop on
> suspend. However, it is corrected on a regular basis, which implies we
> need to re-evaluate it every once in a while.
>
> Cc: John Stultz <jstultz@...gle.com>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: Stephen Boyd <sboyd@...nel.org>
> Cc: Christopher S. Hall <christopher.s.hall@...el.com>
> Cc: Richard Cochran <richardcochran@...il.com>
> Cc: Lakshmi Sowjanya D <lakshmi.sowjanya.d@...el.com>
> Signed-off-by: Vincent Donnefort <vdonnefort@...gle.com>
>
...
> +static void __hyp_clock_work(struct work_struct *work)
> +{
> +       struct delayed_work *dwork = to_delayed_work(work);
> +       struct hyp_trace_buffer *hyp_buffer;
> +       struct hyp_trace_clock *hyp_clock;
> +       struct system_time_snapshot snap;
> +       u64 rate, delta_cycles;
> +       u64 boot, delta_boot;
> +       u64 err = 0;
> +
> +       hyp_clock = container_of(dwork, struct hyp_trace_clock, work);
> +       hyp_buffer = container_of(hyp_clock, struct hyp_trace_buffer, clock);
> +
> +       ktime_get_snapshot(&snap);
> +       boot = ktime_to_ns(snap.boot);
> +
> +       delta_boot = boot - hyp_clock->boot;
> +       delta_cycles = snap.cycles - hyp_clock->cycles;
> +
> +       /* Compare hyp clock with the kernel boot clock */
> +       if (hyp_clock->mult) {
> +               u64 cur = delta_cycles;
> +
> +               cur *= hyp_clock->mult;

Mult overflow protection (I see you already have a max_delta value) is
probably needed here.

> +               cur >>= hyp_clock->shift;
> +               cur += hyp_clock->boot;
> +
> +               err = abs_diff(cur, boot);
> +
> +               /* No deviation, only update epoch if necessary */
> +               if (!err) {
> +                       if (delta_cycles >= hyp_clock->max_delta)
> +                               goto update_hyp;
> +
> +                       goto resched;
> +               }
> +
> +               /* Warn if the error is above tracing precision (1us) */
> +               if (hyp_buffer->tracing_on && err > NSEC_PER_USEC)
> +                       pr_warn_ratelimited("hyp trace clock off by %lluus\n",
> +                                           err / NSEC_PER_USEC);

I'm curious in practice, does this come up often? If so, does it
converge down nicely? Have you done much disruption testing using
adjtimex?

> +       }
> +
> +       if (delta_boot > U32_MAX) {
> +               do_div(delta_boot, NSEC_PER_SEC);
> +               rate = delta_cycles;
> +       } else {
> +               rate = delta_cycles * NSEC_PER_SEC;
> +       }
> +
> +       do_div(rate, delta_boot);
> +
> +       clocks_calc_mult_shift(&hyp_clock->mult, &hyp_clock->shift,
> +                              rate, NSEC_PER_SEC, CLOCK_MAX_CONVERSION_S);
> +
> +update_hyp:
> +       hyp_clock->max_delta = (U64_MAX / hyp_clock->mult) >> 1;
> +       hyp_clock->cycles = snap.cycles;
> +       hyp_clock->boot = boot;
> +       kvm_call_hyp_nvhe(__pkvm_update_clock_tracing, hyp_clock->mult,
> +                         hyp_clock->shift, hyp_clock->boot, hyp_clock->cycles);
> +       complete(&hyp_clock->ready);

I'm very forgetful, so maybe it's unnecessary, but for future-you or
just other's like me, it might be worth adding some extra comments to
clarify the assumptions in these calculations.


thanks
-john