linux-kernel - Re: Voyager phys_cpu_present

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]

Message-Id: <1208819332.3640.56.camel@localhost.localdomain>
Date:	Mon, 21 Apr 2008 18:08:52 -0500
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	"H. Peter Anvin" <hpa@...or.com>, Adrian Bunk <bunk@...nel.org>,
	Alexey Starikovskiy <astarikovskiy@...e.de>,
	tglx@...utronix.de, linux-kernel@...r.kernel.org
Subject: Re: Voyager phys_cpu_present_map compile error


On Mon, 2008-04-21 at 22:03 +0200, Ingo Molnar wrote:
> * James Bottomley <James.Bottomley@...senPartnership.com> wrote:
> 
> > > > i ended up excluding Voyager configs from our test space some time 
> > > > ago (and VISWS as well - there's one more visws fix in x86.git), 
> > > > that's how this broke. These subarchitectures seem not to be used 
> > > > at all and the code wont boot on normal PCs. We could mark it 
> > > > BROKEN but the fix seems simple in any case.
> > 
> > I did actually try to avoid these problems by booting the -mc tree on 
> > voyager, but I note that none of these issues showed up in that tree 
> > the last time I did this (admittedly about 3 weeks ago because of 
> > various conferences etc).
> 
> btw., any chance to turn it into a quirk space thing? Voyagers are 
> almost-PCs, right? Most of the Voyager specialities appears to be 
> abstracted away already via smp_ops. I.e. we could have Voyager support 
> in a plain x86 kernel, if CONFIG_X86_VOYAGER is turned on.

Almost, but not quite.  Voyager needs some clickmap work on boot.
However, it should be possible to separate quite a bit of stuff out
using smp ops.

Voyager isn't at all like a PC, I'm afraid.  It's an old unix system
that can emulate a uniprocessor PC when necessary.  The voyager SMP
stuff is incredibly non-PC like, when you get into it.

The boot path for a combined architecture would be boot as PC (UP) and
then detect voyager do the clickmap setup and flip SMP ops before
bringing up the CPUs.  I can think about this for one or two kernel
release cycles down the road.

> quirks we can let survive almost forever - we've still got the math-emu 
> code for example. It's the subarch code we'd like to eliminate 
> eventually. (there are much better abstractions for achieving the same 
> thing: quirks and the genapic code)
> 
> OTOH, i just had a look at it, and it seems a rather special thing - it 
> tries to do like a PC but without actually being a PC. Almost as if it 
> had no or just a little bit of BIOS - the whole Voyager kernel seems to 
> run on the bare metal. Not much point in upsetting that code base i 
> suspect.

It has no bios ... it has something called SUS (Start Up System); it's
actually a RTOS running on a separate 386 processor on the motherboard
to configure things.  SUS can emulate some bios calls, but not very
many.  The BIOS it emulates is an old one, which is why it gets swept
out of the way to configure "advanced" things (like up to 4GB memory).

> let us know if you run into any difficulties with making it to boot 
> again ... nothing truly fundamental should have changed to break it, 
> other that this moving around of SMP code.

It's not actually booting at the moment.  It looks like some issue in
smp_cpus_done.

James


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