Re: Consider changing CONFIG_ACPI default on ARM?

[Demi Marie Obenour <demiobenour@xxxxxxxxx>]

On 8/23/25 22:06, Elliott Mitchell wrote:
> On Sat, Aug 23, 2025 at 08:59:13AM +0100, Julien Grall wrote:
>>
>> On 22/08/2025 21:09, Elliott Mitchell wrote:
>>> Since you're not pointing to anything definite, could it be everything
>>> has been resolved?
>>
>> Unfortunately, the situation has not changed since your last thread about
>> enabling CONFIG_ACPI=y a couple of years ago. The main feature we are
>> lacking is the parsing the IORT (used to discover SMMUs and MSI
>> controllers). Without this...
> 
> No one to sponsor this work?  Disappointing with how far ACPI support had
> gotten.  Surprising the funding ended here.
> 
>>>  We've got at least two people for whom ACPI on ARM
>>> works pretty well.
>>
>> ... Xen will only properly boot on "simple" case like the Raspberry PI.
>> Also, IIRC Xen would use ACPI rather than Device-Tree by default.
> 
> What is the "improper" booting on non-simple cases like?  panic()?
> Domain 0 boots, but the system isn't properly protected by the SMMU?
> Ideally it would be runtime configurable with the former being the
> default, but the panic message indicating how to override to produce the
> latter.  Perhaps even accompanied by an invitation for sponsorship.
> 
> Yet handling those simple cases would help many people.  For a long time
> IO-MMUs were rare, yet the world did not end.
> 
>>> There may be many more using it.  Perhaps this
>>> should even be done on the 4.20 branch given how long this has been
>>> working?
>>
>> I am guessing you mean 4.21 which will be released in a couple of months
>> time, correct?
> 
> As it is very simple to flip the default, I was thinking it might be
> worthwhile to change it on earlier versions too.  After all it has
> actually been known to work for kind of a long time.
> 
>> We have been discussing among the committers on whether we are ok to enable
>> ACPI despite the fact it is still not feature complete (see above). The
>> discussion is not fully finalized but if we were to enable CONFIG_ACPI=y by
>> default then I think we would need the following:
>>
>>  * Select device-tree by default rather than ACPI
>>  * Go through SUPPORT.MD and check what features we marked as SUPPORTED.md
>> but doesn't work on ACPI.
>>
>> Maybe you can help with that?
> 
> I'm not sure this is a good role for me.  I suppose I could do a first
> pass marking everything as non-ACPI.  Problem is most recently I've been
> focussing on another aspect and I would mostly be guessing about things.
> 
>> Out of interest, sorry if this was already mentioned before, is there any
>> reason ACPI is used on the Raspberry PI over Device-Tree? Is there any issue
>> with the latter on Xen?
> 
> Issue is various Linux distributions have differing levels of support for
> various targets.  Nearly everyone has some degree of support for
> Raspberry PI (even Tianocore!), but the quality does vary from
> distribution to distribution.
> 
> My favored distribution is rather limited in what it does for !x86.
> Everything gets built for !x86, but things such as booting hasn't been
> heavily looked at.  There is agreement using U-Boot/UEFI => GRUB would
> likely be a Good Thing, but there is a shortage of people with the right
> expertise to get that working.  As a result booting Xen is troublesome.
> 
> Whereas copying the Tianocore firmware into place and getting it booting
> is *extremely* simple.  Further this has very few restrictions (GPT and
> a ~200MB FAT filesystem).  Better yet once in place this is extremely
> robust.
> 
> The only argument in favor of device-trees I've seen is that they're easy
> to deal with.  Certainly they need little runtime processing.  Yet they
> come with a major weakness that they're really part of the kernel.  When
> the Linux kernel is replaced (even patch-level differences) you pretty
> well always need to replace the device-trees.  Once you've done that it
> is quite difficult to go back to the earlier kernel.
> 
> New device-trees often cause older kernels to panic or malfunction.  If
> storage is on USB you can unplug and adjust on a nearby desktop, but this
> means you need to keep another system handy.  Whereas due to being well
> isolated from the OS, the same set of ACPI tables works for many OSes and
> nearly all versions of Linux.
> 
> The instances of ACPI tables which worked with Windows, but failed for
> other operating systems are quite famous.  The instances where a given
> set of device-trees work with Linux, but then fail with other OSes
> (or even merely different version of Linux) are not notable.  In fact
> instances where device-trees *don't* change drastically between kernel
> minor versions are newsworthy.

I think one proper answer is to bundle the device trees with the kernel,
and to make sure Xen uses the same code to handle it as Linux does.
Both are GPLv2 so it is fine to move code back and forth between them.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

Attachment: OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature