Re: [PATCH] xen/arm64: Default ACPI support enabled

[Elliott Mitchell <ehem+xen@xxxxxxx>]

On Mon, Feb 06, 2023 at 10:38:32AM +0000, Julien Grall wrote:
> 
> On 06/02/2023 07:29, Jan Beulich wrote:
> > On 22.07.2020 19:43, Elliott Mitchell wrote:
> >> Unlike other unsupportted options, ACPI support is required to *boot*
> >> for a number of platforms.  Users on these platforms are unable to use
> >> distribution builds and must rebuild from source to use Xen.
> >>
> >> Signed-off-by: Elliott Mitchell <ehem+xen@xxxxxxx>
> > 
> > A general question first: How come this mail dates back to July 2020? I
> > had almost missed it as "new".
> 
> I can't even find the Elliott's email in my inbox so reply here. But 
> this sounds like a rehash of [1].

The date on Git patches is meant as an indicator for author date.  Since
this is a cherry-pick of a patch which was written >2 years ago
`git format-patch` indicates when it was written.  This IS how these
systems work.


>  >> Unlike other unsupportted options, ACPI support is required to *boot*
>  >> for a number of platforms.  Users on these platforms are unable to use
>  >> distribution builds and must rebuild from source to use Xen.
> 
> What platforms are you testing on? I know that this is working-ish on 
> RPI4 and QEMU. But this will likely blow up on one of the server we 
> support in OSSTest because we don't have proper support to hide SMMUs in 
> dom0.

I've been doing RPI4 w/EDK2.  Which works for my purpose, the remaining
trouble spot for my purpose is needing a final resolution of the EFIFB
situation.

> >> --- a/xen/arch/arm/Kconfig
> >> +++ b/xen/arch/arm/Kconfig
> >> @@ -29,13 +29,18 @@ menu "Architecture Features"
> >>   source "arch/Kconfig"
> >>   
> >>   config ACPI
> >> -  bool "ACPI (Advanced Configuration and Power Interface) Support 
> >> (UNSUPPORTED)" if UNSUPPORTED
> >> +  bool "ACPI (Advanced Configuration and Power Interface) Support 
> >> (UNSUPPORTED)"
> 
> The concerns I raised in [1] still stand. Most of the ACPI platform will 
> also have support for IOMMUs. If we have support for IORT in Xen, then I 
> would be a lot more amenable to remove the "UNSUPPORTED". And without 
> that support we are going to do more harm and than good.

Okay, this has been a known issue for *years* and yet remains unresolved
despite being a major issue.  Might be an abomination, but would it work
to find the string "IORT" and change it to "iort", "RTIO" or "IOXN" to
prevent Dom0 from finding it?

This ends up turning into a question of what are the cases and which are
more common?

Case1: DT-only: Unchanged

Case2: Switchable between DT and ACPI, w/o SMMU: Starts working with ACPI

Case3: Switchable between DT and ACPI, w/SMMU: Unchanged, ACPI mode still
doesn't work, but the failure is different.

Case4: Concurrent DT and ACPI support, w/o SMMU: Unchanged

Case5: Concurrent DT and ACPI support, w/SMMU: Breaks if Dom0 tries to
use ACPI

Case6: ACPI-only, w/o SMMU: Starts working out-of-box

Case7: ACPI-only, w/SMMU: Unchanged (still broken)

Any other distinct cases of note?


So case 5 is a problem, but cases 2 and 6 are positive.  Does the classic
workaround of "acpi=off" work for Linux as Dom0?  If that is "yes", then
publicizing that workaround (should be detectable by Xen) seems a likely
short-term solution.

My impression is ACPI is getting increasing support in on ARM.  The
number of mentions suggests if they keep going it looks likely to win.
The EDK2 project has been providing an image for RPI4 and the
functionality is impressive.

Ultimately this is more a decision for Xen Project management, than the
technical side.  Are things in shape where they can be rolled out?  Is
ACPI support important enough to need rolling out now?

I'm unsure about the former, but the latter seems a distinct "yes" since
ACPI appears to be the future.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@xxxxxxx  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445