[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.