Re: [PATCH v3 01/11] x86/boot: enumerate documentation for the x86 hardware_subarch

["Luis R. Rodriguez" <mcgrof@kernel.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 <mcgrof@kernel.org> 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 <andriy.shevchenko@linux.intel.com>
> > > Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
> > > ---
> > >  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