Re: [PATCH 10/11] x86/xip: resolve alternative instructions at build

[Jim Kukunas <james.t.kukunas@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 2686 bytes --]

On Mon, Mar 23, 2015 at 09:33:02AM +0100, Borislav Petkov wrote:
> On Mon, Mar 23, 2015 at 12:46:39AM -0700, Jim Kukunas wrote:
> > Since the .text section can't be updated at run-time, remove the
> > .alternatives sections and update the .text at build time. To pick the
> > proper instructions, Kconfig options are exposed for each X86_FEATURE
> > that needed to be resolved. Each X86_FEATURE gets a corresponding
> > CONFIG_XIP_ENABLE_X86_FEATURE_ option. Based on whether this option
> > is set, a resolver macro is setup to either generate that instruction,
> > or the fallback. The resolver needs to be defined for each FEATURE, and
> > the proper one is chosen via preprocessor string pasting.
> > 
> > This approach is horrific and ugly.
> 
> You said it.
> 
> And with XIP enabled - whatever that means, your announce message could
> explain a lot more and more verbosely what this whole patchset is all
> about - this kernel is not going to be generic anymore but it will be
> destined only for the machine it is being built for, correct?

Please see my response to Ingo for more information about the patchset.

Yes, regardless of how it's implemented, selecting alternatives at build
time will produce a non-generic kernel (unless all alternative instructions
are disabled and just the fallbacks are used).

> If that is so, how are distros supposed to ship one kernel with XIP or
> is this some obscure feature distros won't have to enable anyway?

XIP isn't a general feature that distros are going to be enabling. It's 
designed for a very specific usage where people are building very custom
kernels.

> Concerning this particular patch, I'd suggest a switch which simply
> disables alternatives patching at run time so that you don't add this
> ifdeffery to alternative.c

I'll look into this.

> Btw, why do you even have to disable the alternatives? I see this in
> your patch 1/11:
> 
> +         location in RAM. As a result, when the kernel is located in storage
> +         that is addressable by the CPU, the kernel text and read-only data
> +         segments are never loaded into memory, thereby using less RAM.
> 
> is this it? To save some memory? Probably embedded, maybe some light
> bulb running linux... Yuck.

Alternatives are disabled because the kernel text will be read-only. For
example, consider the kernel image being stored in and executing from
ROM. Cutting the kernel text and read-only data out of RAM really helps
Linux scale down to smaller systems.

So yes, it's for embedded. Linux has a lot to offer in that area.

Thanks.

-- 
Jim Kukunas
Intel Open Source Technology Center

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]