From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Luis R. Rodriguez" Subject: Re: [PATCH v3 01/11] x86/boot: enumerate documentation for the x86 hardware_subarch Date: Tue, 23 Feb 2016 21:41:35 +0100 Message-ID: <20160223204135.GH25240@wotan.suse.de> References: <1456212255-23959-1-git-send-email-mcgrof@kernel.org> <1456212255-23959-2-git-send-email-mcgrof@kernel.org> <20160223085119.GA10182@gmail.com> <20160223103409.GF25240@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20160223103409.GF25240@wotan.suse.de> Sender: linux-kernel-owner@vger.kernel.org To: "Luis R. Rodriguez" Cc: Ingo Molnar , bp@alien8.de, hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com, rusty@rustcorp.com.au, x86@kernel.org, linux-kernel@vger.kernel.org, luto@amacapital.net, boris.ostrovsky@oracle.com, david.vrabel@citrix.com, konrad.wilk@oracle.com, xen-devel@lists.xensource.com, lguest@lists.ozlabs.org, Andy Shevchenko , Andrew Cooper List-Id: xen-devel@lists.xenproject.org On Tue, Feb 23, 2016 at 11:34:09AM +0100, Luis R. Rodriguez wrote: > On Tue, Feb 23, 2016 at 09:51:19AM +0100, Ingo Molnar wrote: > > > > * Luis R. Rodriguez wrote: > > > > > Although hardware_subarch has been in place since the x86 boot > > > protocol 2.07 it hasn't been used much. Enumerate current possible > > > values to avoid misuses and help with semantics later at boot > > > time should this be used further. > > > > > > v2: fix typos > > > > > > Cc: Andy Shevchenko > > > Signed-off-by: Luis R. Rodriguez > > > --- > > > arch/x86/include/uapi/asm/bootparam.h | 31 ++++++++++++++++++++++++++++++- > > > 1 file changed, 30 insertions(+), 1 deletion(-) > > > > > > diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h > > > index 329254373479..50d5009cf276 100644 > > > --- a/arch/x86/include/uapi/asm/bootparam.h > > > +++ b/arch/x86/include/uapi/asm/bootparam.h > > > @@ -157,7 +157,36 @@ struct boot_params { > > > __u8 _pad9[276]; /* 0xeec */ > > > } __attribute__((packed)); > > > > > > -enum { > > > +/** > > > + * enum x86_hardware_subarch - x86 hardware subarchitecture > > > + * > > > + * The x86 hardware_subarch and hardware_subarch_data were added as of the x86 > > > + * boot protocol 2.07 to help distinguish and supports custom x86 boot > > > + * sequences. This enum represents accepted values for the x86 > > > + * hardware_subarch. Custom x86 boot sequences (not X86_SUBARCH_PC) do not have > > > + * or simply do not make use of natural stubs like BIOS or EFI, the > > > + * hardware_subarch can be used on the Linux entry path to revector to a > > > + * subarchitecture stub when needed. This subarchitecture stub can be used to > > > + * set up Linux boot parameters or for special care to account for nonstandard > > > + * handling of page tables. > > > + * > > > + * KVM and Xen HVM do not have a subarch as these are expected to follow > > > + * standard x86 boot entries. If there is a genuine need for "hypervisor" type > > > + * that should be considered separately in the future. > > > + * > > > + * @X86_SUBARCH_PC: Should be used if the hardware is enumerable using standard > > > + * PC mechanisms (PCI, ACPI) and doesn't need a special boot flow. > > > + * @X86_SUBARCH_LGUEST: Used for x86 hypervisor demo, lguest > > > + * @X86_SUBARCH_XEN: Used for Xen guest types which follow the PV boot path, > > > + * which start at asm startup_xen() entry point and later jump to the C > > > + * xen_start_kernel() entry point. > > > + * @X86_SUBARCH_INTEL_MID: Used for Intel MID (Mobile Internet Device) platform > > > + * systems which do not have the PCI legacy interfaces. > > > + * @X86_SUBARCH_CE4100: Used for Intel CE media processor (CE4100) SOC for > > > + * for settop boxes and media devices, the use of a subarch for CE4100 > > > + * is more of a hack... > > > + */ > > > +enum x86_hardware_subarch { > > > X86_SUBARCH_PC = 0, > > > X86_SUBARCH_LGUEST, > > > X86_SUBARCH_XEN, > > > > No, this is really backwards. > > > > While I agree that we want to get rid of paravirt_enabled(), we _dont_ want to > > spread the use of (arguably broken) boot flags like this! > > I agree that we should not see the spread of boot flags around general x86 > code, its not my goal to spread it though, the code that uses it here though is > *early boot code* (although in retrospect the pnpbios use was a fuckup), and I > have some special considerations for early boot code which I think does give > merit to it use. But also keep in mind my goal is to rather fold the boot flag > so its more just an architectural consideration eventually. More on this below. It seems I TL;DR suck; all this is a long winded way of asking, can we keep the subarch just for EBDA and use the flags for the other things as you noted? Luis