linux-kernel - Re: [BUG] x86 kenel won't boot under Virtual PC

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, 8 Sep 2008 09:34:15 -0700 (PDT)
From:	david@...g.hm
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	"H. Peter Anvin" <hpa@...or.com>, Andi Kleen <andi@...stfloor.org>,
	linux@...dersweb.net, linux-kernel@...r.kernel.org,
	the arch/x86 maintainers <x86@...nel.org>,
	Andi Kleen <andi-suse@...stfloor.org>
Subject: Re: [BUG] x86 kenel won't boot under Virtual PC

On Mon, 8 Sep 2008, Linus Torvalds wrote:

> On Mon, 8 Sep 2008, H. Peter Anvin wrote:
>>
>> And yes, it should be the default.  The patch I have makes it
>> "default y" as well as change the help text.
>
> It sounds like it shouldn't be a default at all, it should just _always_
> be on, if there really are gcc's that care that much. Most of our
> optimizations have historically really been about _optimizing_, not about
> "it won't work", even if we have had exceptions (but as mentioned, I think
> those exceptions have been way more imporant than NOPL).
>
>> Would it make you happier if this option was forced enabled unless
>> CONFIG_EMBEDDED was on?
>
> Yes, putting it behind EMBEDDED will certainly fix the issue. Anybody who
> actually enables EMBEDDED and does all his choices by hand should no
> longer expect to not have to know _exactly_ what he is doing.
>
> So if it's behind EMBEDDED, and defaults to "on", then I have no problem
> with changing the help text to say "If you do this, we'll statically do
> things that really _require_ you to have a CPU that looks _exactly_ like
> the CPU you claimed".

I always understood the CPU selection to be "this CPU and ones compatible 
with it will work, others won't" unless generic was enabled. the fact that 
only a few CPU's wouldn't work and the rest was optimization is true, but 
the details of what chips would and wouldn't work were never that clear. 
The difference between a kernel compiled for generic and once compiled for 
a specific CPU can be very significant. (I ran into 30% differences back 
in the 2.4 days between generic and Athlon) This is why all the distros 
don't enable the generic cpu option on their kernels nowdays. I'd hate to 
see all the distros enabling embedded just to get this performance boost

David Lang
--
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/