| 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
| ||
|
Date: Tue, 29 Oct 2013 14:23:43 +0100 From: Peter Zijlstra <peterz@...radead.org> To: David Ahern <dsahern@...il.com> Cc: Gleb Natapov <gleb@...hat.com>, 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 Mon, Oct 28, 2013 at 08:58:08PM -0600, David Ahern wrote: > 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). Fair enough; but then I don't know how to get things faster than what your initial patch proposes to do. Typically the only way to get things faster is avoiding VM exits is by replicating state inside the guest, but as you say, that ends up being complex/fragile. -- 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/
Powered by blists - more mailing lists