linux-kernel - Re: + stupid-hack-to-make-mainline-build.patch added to -mm tree

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <45EFCC3C.5090201@goop.org>
Date:	Thu, 08 Mar 2007 00:41:32 -0800
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Ingo Molnar <mingo@...e.hu>
CC:	tglx@...utronix.de, Dan Hecht <dhecht@...are.com>,
	Zachary Amsden <zach@...are.com>, akpm@...ux-foundation.org,
	ak@...e.de,
	Virtualization Mailing List <virtualization@...ts.osdl.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	LKML <linux-kernel@...r.kernel.org>,
	john stultz <johnstul@...ibm.com>
Subject: Re: + stupid-hack-to-make-mainline-build.patch added to -mm tree

Ingo Molnar wrote:
> 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'.

Sure.  But the specific case we're talking about here is a 300 line
clock driver.  Nothing about its implementation has any effect on the
kernel's APIs or abstractions.

>  I'd expect hypercalls 
> to be put into silicon just as much as SYSENTER was put into silicon. 
>   
Sysenter is marginally faster than int $80, but not massively so.  I
guess Xen could use sysenter now for hypercalls, since its only useful
for getting into ring 0.

> 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'. 
Well, if you have a hypervisor scheduler multiplexing vcpus onto a real
cpu at 100hz and a kernel scheduler multiplexing processes onto a vcpu
at 100hz, then you're going to get a lot of disappointed processes who
nominally got their 10ms real-time slice, but it was all spent on some
other vcpu.   Its important that the kernel's scheduler know how much
vcpu time each process really got, rather than basing its scheduling on
the amount of real time that passed.

> The TSC 
> is awfully unreliable.
>   
Sure.

> /THIS/ is the kind of junk we are trying to protect Linux against. 
>   

What?  That Xen happens to use the tsc as part of its hypervisor
interface?  A fact that's completely isolated from the rest of the
kernel behind the clock subsystem?

    J
-
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/