netdev - Re: [RFC PATCH 1/5] x86: tsc: add tsc to art helpers

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: <87y2y4vk4g.fsf@gmail.com>
Date:   Tue, 01 Oct 2019 13:24:31 +0300
From:   Felipe Balbi <felipe.balbi@...ux.intel.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Richard Cochran <richardcochran@...il.com>, netdev@...r.kernel.org,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H . Peter Anvin" <hpa@...or.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org,
        "Christopher S . Hall" <christopher.s.hall@...el.com>
Subject: Re: [RFC PATCH 1/5] x86: tsc: add tsc to art helpers


Hi,

(sorry for the long delay, got caught up in other tasks)

Thomas Gleixner <tglx@...utronix.de> writes:
> On Thu, 15 Aug 2019, Felipe Balbi wrote:
>> Thomas Gleixner <tglx@...utronix.de> writes:
>> > On Tue, 16 Jul 2019, Felipe Balbi wrote:
>> >
>> > So some information what those interfaces are used for and why they are
>> > needed would be really helpful.
>> 
>> Okay, I have some more details about this. The TGPIO device itself uses
>> ART since TSC is not directly available to anything other than the
>> CPU. The 'problem' here is that reading ART incurs extra latency which
>> we would like to avoid. Therefore, we use TSC and scale it to
>> nanoseconds which, would be the same as ART to ns.
>
> Fine. But that's not really correct:
>
>       TSC = art_to_tsc_offset + ART * scale;

From silicon folks I got the equation:

ART = ECX * EBX / EAX;

If I'm reading this correctly, that's basically what
native_calibrate_tsc() does (together with some error checking the safe
defaults). Couldn't we, instead, just have a single function like below?

u64 convert_tsc_to_art_ns()
{
	return x86_platform.calibrate_tsc();
}

Another way would be extract the important parts from
native_calibrate_tsc() into a separate helper. This would safe another
call to cpuid(0x15,...);

>> >> +void get_tsc_ns(struct system_counterval_t *tsc_counterval, u64 *tsc_ns)
>
> Why is this not returning the result instead of having that pointer
> indirection?

That can be changed easily, no worries.

>> >> +{
>> >> +	u64 tmp, res, rem;
>> >> +	u64 cycles;
>> >> +
>> >> +	tsc_counterval->cycles = clocksource_tsc.read(NULL);
>> >> +	cycles = tsc_counterval->cycles;
>> >> +	tsc_counterval->cs = art_related_clocksource;
>
> So this does more than returning the TSC time converted to nanoseconds. The
> function name should reflect this. Plus both functions want kernel-doc
> explaining what they do.

convert_tsc_to_art_ns()? That would be analogous to convert_art_to_tsc()
and convert_art_ns_to_tsc().

cheers

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)