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

From: Stefano Stabellini <sstabellini@kernel.org>
To: Julien Grall <julien@xen.org>
Cc: Elliott Mitchell <ehem+xen@m5p.com>,
	xen-devel@lists.xenproject.org,
	 Stefano Stabellini <sstabellini@kernel.org>,
	 Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: Re: [PATCH] xen/arm: Remove EXPERT dependancy
Date: Thu, 22 Oct 2020 14:17:13 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.21.2010221403570.12247@sstabellini-ThinkPad-T480s> (raw)
In-Reply-To: <7bf92deb-b1ba-31b2-0357-2639cd2a1bca@xen.org>

On Thu, 22 Oct 2020, Julien Grall wrote:
> On 22/10/2020 02:43, Elliott Mitchell wrote:
> > Linux requires UEFI support to be enabled on ARM64 devices.  While many
> > ARM64 devices lack ACPI, the writing seems to be on the wall of UEFI/ACPI
> > potentially taking over.  Some common devices may need ACPI table
> > support.
> > 
> > Presently I think it is worth removing the dependancy on CONFIG_EXPERT.
> 
> The idea behind EXPERT is to gate any feature that is not considered to be
> stable/complete enough to be used in production.

Yes, and from that point of view I don't think we want to remove EXPERT
from ACPI yet. However, the idea of hiding things behind EXPERT works
very well for new esoteric features, something like memory introspection
or memory overcommit. It does not work well for things that are actually
required to boot on the platform.

Typically ACPI systems don't come with device tree at all (RPi4 being an
exception), so users don't really have much of a choice in the matter.

From that point of view, it would be better to remove EXPERT from ACPI,
maybe even build ACPI by default, *but* to add a warning at boot saying
something like:

"ACPI support is experimental. Boot using Device Tree if you can."

That would better convey the risks of using ACPI, while at the same time
making it a bit easier for users to boot on their ACPI-only platforms.

> I don't consider the ACPI complete because the parsing of the IORT (used to
> discover SMMU and GICv3 ITS) is not there yet.
> 
> I vaguely remember some issues on system using SMMU (e.g. Thunder-X) because
> Dom0 will try to use the IOMMU and this would break PV drivers.

I am not sure why Dom0 using the IOMMU would break PV drivers? Is it
because the pagetable is not properly updated when mapping foreign
pages?

> Therefore I think we at least want to consider to hide SMMUs from dom0 before
> removing EXPERT. Ideally, I would also like the feature to be tested in
> Osstest.
> 
> The good news is Xen Project already has systems (e.g. Thunder-X, Softiron)
> that can supported ACPI. So it should hopefully be a matter to tell them to
> boot with ACPI rather than DT.

I agree that we want to keep ACPI "expert/experimental" given its
current state but maybe we can find a better way to carry that message
than to set EXPERT in Kconfig.

And yes, if we wanted to make ACPI less "expert/experimental" we
definitely need some testing in OSSTest and any critical bugs (e.g. PV
drivers not working) addressed.