From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752547AbbCYAux (ORCPT ); Tue, 24 Mar 2015 20:50:53 -0400 Received: from mga14.intel.com ([192.55.52.115]:60423 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751876AbbCYAut (ORCPT ); Tue, 24 Mar 2015 20:50:49 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,461,1422950400"; d="scan'208";a="703689134" Date: Tue, 24 Mar 2015 17:50:49 -0700 From: Jim Kukunas To: Borislav Petkov Cc: Linux Kernel , tom.zanussi@linux.intel.com, Arjan van de Ven , "H. Peter Anvin" , tglx@linutronix.de, mingo@redhat.com, x86@kernel.org Subject: Re: [PATCH 10/11] x86/xip: resolve alternative instructions at build Message-ID: <20150325005049.GB2600@jtk-ivb.jf.intel.com> Mail-Followup-To: Borislav Petkov , Linux Kernel , tom.zanussi@linux.intel.com, Arjan van de Ven , "H. Peter Anvin" , tglx@linutronix.de, mingo@redhat.com, x86@kernel.org References: <1427096800-30452-1-git-send-email-james.t.kukunas@linux.intel.com> <1427096800-30452-11-git-send-email-james.t.kukunas@linux.intel.com> <20150323083301.GA31992@pd.tnic> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uQr8t48UFsdbeI+V" Content-Disposition: inline In-Reply-To: <20150323083301.GA31992@pd.tnic> User-Agent: Mutt/1.5.20 (2009-12-10) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --uQr8t48UFsdbeI+V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. > >=20 > > This approach is horrific and ugly. >=20 > You said it. >=20 > 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=20 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: >=20 > + location in RAM. As a result, when the kernel is located in sto= rage > + that is addressable by the CPU, the kernel text and read-only d= ata > + segments are never loaded into memory, thereby using less RAM. >=20 > 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. --=20 Jim Kukunas Intel Open Source Technology Center --uQr8t48UFsdbeI+V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iQIcBAEBAgAGBQJVEgZpAAoJEJsd5ffp0QqMXyYP/R5AOJ8rpUV/W9nVVG4e7lS9 NiIWEhhmivkLmzle26o/3G0mZyUZPQ/zcSgeMD/wkmF02XW9AW6DhcxNUYqpL++x gJY7GkJqUiXcv+UO6XoDoKLYQAfaUlNvJTkWXCxLVlOxTVagzxk4vJtUBHzCuloB 6KbsJvakMlKWHloYgyxZbOaTkgIq1u5KaA1DL3vrf+3Hf/6Iyr8hTwZPuYh49aLm 93W4akpyUbMbiCqbS7JYHkrol2VG75czo0VCXJIilhlQrXeXOm6h0LmmwDqqPHX2 SX33e+xAt6VK2my4EmBSGiu9KHAs8/oW9FE038Zf5Iv6XWgb0+TwdQvkcZuHEo9X 005T4Mjc2xgCV6L7v2m9WhnxB8d0eKEAGu5M8lcmrtCp0GTkXRgIMZiXlq4vqOzH Ao9sw6hs+Qn9PEk6UQsdeA0sR0pHdsZaN8wDFPCBQfweHJJ3mhG2A8eQrYwhIqAQ AsK4m/pN+uDoze9je6vuEzlVF59EWI/PH1KnYWtOi278MT379es5Te8aWk6fMnV4 vIzkee+8DsBgCk6yUw4hYl97YtN96gz6yyxHUfPmS9kEgZuhkNDJum0O+dQiN/lI pr3YcRH8lCDL3y9P+bvyrO9SCGdQKW7baVza/caxtSIkVWR9/5eWH2SSldEarA/P VoL+mEpxyzqtOWj/i8l4 =Ppke -----END PGP SIGNATURE----- --uQr8t48UFsdbeI+V--