linux-kernel - Re: RFC: paravirtualizing perf

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]

Date:	Mon, 28 Oct 2013 20:58:08 -0600
From:	David Ahern <dsahern@...il.com>
To:	Peter Zijlstra <peterz@...radead.org>,
	Gleb Natapov <gleb@...hat.com>
CC:	Ingo Molnar <mingo@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>, KVM <kvm@...r.kernel.org>,
	yoshihiro.yunomae.ez@...achi.com
Subject: Re: RFC: paravirtualizing perf_clock

On 10/28/13 7:15 AM, Peter Zijlstra wrote:
>> Any suggestions on how to do this and without impacting performance. I
>> noticed the MSR path seems to take about twice as long as the current
>> implementation (which I believe results in rdtsc in the VM for x86 with
>> stable TSC).
>
> So assuming all the TSCs are in fact stable; you could implement this by
> syncing up the guest TSC to the host TSC on guest boot. I don't think
> anything _should_ rely on the absolute TSC value.
>
> Of course you then also need to make sure the host and guest tsc
> multipliers (cyc2ns) are identical, you can play games with
> cyc2ns_offset if you're brave.
>

This and the method Gleb mentioned both are going to be complex and 
fragile -- based assumptions on how the perf_clock timestamps are 
generated. For example, 489223e assumes you have the tracepoint enabled 
at VM start with some means of capturing the data (e.g., a perf-session 
active). In both cases the end result requires piecing together and 
re-generating the VM's timestamp on the events. For perf this means 
either modifying the tool to take parameters and an algorithm on how to 
modify the timestamp or a homegrown tool to regenerate the file with 
updated timestamps.

To back out a bit, my end goal is to be able to create and merge 
perf-events from any context on a KVM-based host -- guest userspace, 
guest kernel space, host userspace and host kernel space (userspace 
events with a perf-clock timestamp is another topic ;-)). Having the 
events generated with the proper timestamp is the simpler approach than 
trying to collect various tidbits of data, massage timestamps (and 
hoping the clock source hasn't changed) and then merge events.

And then for the cherry on top a design that works across architectures 
(e.g., x86 now, but arm later).

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