linux-kernel - RE: [Xen-devel] Re: [PATCH 3/5] x86/pvclock: add vsyscall implementation

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:	Thu, 5 Nov 2009 06:52:38 -0800 (PST)
From:	Dan Magenheimer <dan.magenheimer@...cle.com>
To:	Avi Kivity <avi@...hat.com>
Cc:	Jeremy Fitzhardinge <jeremy@...p.org>,
	Glauber Costa <glommer@...hat.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>,
	kurt.hackel@...cle.com, the arch/x86 maintainers <x86@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Glauber de Oliveira Costa <gcosta@...hat.com>,
	Xen-devel <xen-devel@...ts.xensource.com>,
	Keir Fraser <keir.fraser@...citrix.com>, zach.brown@...cle.com,
	chris.mason@...cle.com, Ingo Molnar <mingo@...hat.com>
Subject: RE: [Xen-devel] Re: [PATCH 3/5] x86/pvclock: add vsyscall
	implementation

> From: Avi Kivity [mailto:avi@...hat.com]
> 
> Within a process, yes.  Across processes, not without writable shared 
> memory.
> 
> That's why I'm trying to understand what the actual 
> requirements are.  
> Real monotonic, accurate, high resolution, low cost time sources are 
> hard to come by.

Hmmm... this has significant implications for the rdtsc
emulation discussion on xen-devel.  Since that's not
a Linux question, I'll start another thread on xen-devel
with a shorter cc list.

> > Actually, I think for many/most profiling applications,
> > just knowing a discontinuity occurred between two
> > timestamps is very useful as that one specific measurement
> > can be discarded.  If a discontinuity is invisible,
> > one clearly knows that a negative interval is bad,
> > but if an interval is very small or very large,
> > one never knows if it is due to a discontinuity or
> > due to some other reason.
> >
> > This would argue for a syscall/vsyscall that can
> > "return" two values: the "time" and a second
> > "continuity generation" counter.
> 
> I doubt it.  You should expect discontinuities in user space due to 
> being swapped out, scheduled out, migrated to a different 
> cpu, or your 
> laptop lid being closed.  There are no guarantees to a userspace 
> application.  Even the kernel can expect discontinuities due 
> to SMIs.  
> So an explicit notification about one type of discontinuity 
> adds nothing.

Good point.  I'm interested in enterprise apps that have more
control over the machine (and rarely suffer from laptop lid
closures :-) and would intend for all discontinuities visible
to a hypervisor or kernel to increment "AUX", but bare-metal-
kernel-invisible discontinuities such as SMI do throw a wrench
in the works.

Well, all this discussion has convince me that
my original proposals do make sense for enterprise apps to be
virtualization-aware and use rdtsc/p directly for timestamping
needs rather than OS APIs (with the hypervisor deciding
whether or not to emulate rdtsc/p based on the underlying
physical machine and whether or not migration is enabled
or has occurred).
--
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/