Re: [PATCH] xen/arm: Remove EXPERT dependancy

[Julien Grall <julien@xxxxxxx>]

Hi Elliott,

On 04/11/2020 19:03, Elliott Mitchell wrote:
> On Mon, Oct 26, 2020 at 09:19:49AM +0000, Julien Grall wrote:
> > On 23/10/2020 17:57, Stefano Stabellini wrote:
> > > On Fri, 23 Oct 2020, Julien Grall wrote:
> > > > I am sort of okay to remove EXPERT.
> > > OK. This would help (even without building it by default) because as you
> > > go and look at the menu the first time, you'll find ACPI among the
> > > options right away.
> > To be honest, this step is probably the easiest in the full process to
> > get Xen build and booted on Arm.
> >
> > I briefly looked at Elliot's v2, and I can't keep thinking that we are
> > trying to re-invent EXPERT for ACPI because we think the feature is
> > *more* important than any other feature gated by EXPERT.
> Yet might that statement in fact be true?
Everyone has a different opinion on what's important or not. I am sure 
we can spend hours bikeshedding on that...
> Most of the features currently controlled by CONFIG_EXPERT are relatively
> small tweaks which enable less often used features.  Some of those are
> very high value in certain environments, but they're unimportant in
> common environments.  Changing the scheduler might get you an extra
> 10-50% performance improvement in a special environment.
>
> ACPI support isn't like this.  I'm unaware what Masami Hiramatsu's system
> does if a CONFIG_ACPI=n Xen build is tried.  I haven't actually tried
> such a build on mine, but from the code it looks like Xen would panic if
> built that way.  No output of any sort.  Simply panic with the device
> appearing to go inert.
There will always be cases where the console is not working:
  1) There is no driver in Xen
  2) There is no SPCR table present

I think you are in the second situation and you had to enable 
earlyprintk. Is that correct?
> > In fact, all the features behind EXPERT are important. But they have
> > been gated by EXPERT because they are not mature enough.
> > But I don't think ACPI is mature enough to deserve a different
> > treatment. It would be more useful to get to the stage where ACPI can
> > work without any crash/issue first.
> The difference is the severity of failure if the option is off, but needs
> to be on.  Most CONFIG_EXPERT options will merely be performance
> reductions or security situations unacceptable to some users.
> CONFIG_ACPI=n on the wrong system could be a panic with *no* output. >
>
> Tainting sounds reasonable.  Messages in `dmesg` make sense.  A message
> plus 10 second pause on boot seems reasonable.  I think if CONFIG_ACPI is
> off, there should be code to try to detect ACPI and emit a warning if
> anything is detected.
All of this would be moot if we focus on getting ACPI (or just a subset) 
working on a few platforms (e.g. RPI, Thunder-X).
I don't think we are too far from this acheviement. This would be IMHO 
be enough to move ACPI one way up in the support "ladder". We might even 
be able to do this for 4.15.
Cheers,

--
Julien Grall