linux-kernel - Re: [PATCH 3/9] x86/moorestown: add moorestown platform flags

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]

Date:	Fri, 26 Jun 2009 11:16:03 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	"Pan, Jacob jun" <jacob.jun.pan@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...ux.intel.com>
Subject: Re: [PATCH 3/9] x86/moorestown: add moorestown platform flags

> It's an entirely legitimate question, given that many other current 
> modern subarchitectures detect themselves based on PCI config space 
> early accesses or (sometimes) BIOS data structures - and that both 
> of those methods are better than using boot flags.

The flags are passed by the boot loader which is the one thing that knows
what the platform is only deeply embedded hardware. See the ARM and PPC
ports.

> > - Embedded x86 like devices are going to regularly occur without 
> > any PCI
> 
> This proposed Intel subarchitecture comes with PCI support, 
> obviously.

And this is relevant to the fact there will be systems without PCI how ?

> > - You need to know the platform in order to know how to access any
> >   PCI bus that may or may not hypothetically exist.
> 
> Uhm, not really.

Uhm yes really

> Have a look at arch/x86/kernel/early-quirks.c. All you generally 
> need to know is a PCI ID that sits on the root bus.

How will you probe the root bus without knowing what the PCI
configuration mechanism is for your platform

> Early PCI ID checks are typical and robust way to identify 'weird' 
> subarchitectures. Sometimes we do it via BIOS data structures. Only 
> as a last option do we want to use boot loader mechanisms - it's the 
> most inflexible one really.

SFI doesn't indicate MRST
> 
> Furtherore, Moorestown comes with SFI and there sure can be a BIOS 
> table that describes the platform properly. We can read such tables 
> very early during bootup, well before platform devices are set up.

But they don't tell you what the platform is. Again see every platform we
currently support which has deeply embedded forms. There is a reason they
went that way and it includes fifteen years of finding out which ways
don't work for all cases. For example if you don't have standard PC like
firmware and you go looking for SFI or ACPI will your box stay up ?

It's also kind of irrelevant to the flags anyway - you need the boot
flags whether the platform comes from the bootloader or divine
intervention somewhere early in probing.

There is a more general question which is whether the flags are better
than the PPC style approach of having a machine vector and putting them
in that so you just do

	platform_ops = platform_ops_table[our_platform]

and use
	platform_ops->

for the various methods such as EBDA and which timer methods to use



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