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  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, 8 Mar 2007 09:01:31 +0100
From:	Ingo Molnar <>
To:	Jeremy Fitzhardinge <>
Cc:, Dan Hecht <>,
	Zachary Amsden <>,,,
	Virtualization Mailing List <>,
	Rusty Russell <>,
	LKML <>,
	john stultz <>
Subject: Re: + stupid-hack-to-make-mainline-build.patch added to -mm tree

* Jeremy Fitzhardinge <> wrote:

> > Your implementation is almost the perfect prototype, if you move the 
> > 128 bit hackery into the hypervisor and hide it away from the kernel 
> > :)
> The point is to use the tsc to avoid making any hypercalls, so dealing 
> with the tsc->ns conversion has to happen on the guest side somehow.

you are obsessed with avoiding a hypercall, but why? Granted it's slow 
especially on things like SVN/VMX, but it's not fundamentally slow. We 
definitely do not want to design our whole APIs and abstractions around 
the temporary notion that 'hypercalls are slow'. I'd expect hypercalls 
to be put into silicon just as much as SYSENTER was put into silicon. 
Anyway, in terms of guest time code, a /big/ amount of design junk can 
be avoided by not trying to do sillynesses like 'virtual time'. The TSC 
is awfully unreliable.

really, it's a bit as if Linus looked at his 386DX CPU when he bought it 
16 years ago and decided that: "this CPU executes 16-bit code much 
faster than 32-bit code, so lets base this new toy OS on 16-bit code. 
Sure, it's a bit of a pain to use, compared to 32-bit code, but users 
demand performance!".

/THIS/ is the kind of junk we are trying to protect Linux against. 
Basically hypervisors are a way to prolong hardware legacies, and 
because unlike real hardware software ABIs dont actually burn out with 
time, and people are stubborn about using them, their effects are alot 
worse and alot longer than that of legacy hardware.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists