On Mon, Aug 25, 2025 at 10:07:18AM +0200, Jan Beulich wrote:
> On 22.08.2025 22:09, Elliott Mitchell wrote:
> > On Fri, Aug 15, 2025 at 10:14:42AM +0200, Jan Beulich wrote:
> >> On 14.08.2025 23:27, Demi Marie Obenour wrote:
> >>> On 8/14/25 02:55, Jan Beulich wrote:
> >>>>
> >>>> Parties interested in changing the support status of any component are
> >>>> the
> >>>> primary candidates to actually carry out the necessary work.
> >>>
> >>> What is that work?
> >>
> >> To determine what exactly needs doing is part of the exercise. I, for one,
> >> am
> >> unaware of a concrete written down set of things which need doing.
> >
> > Since you're not pointing to anything definite, could it be everything
> > has been resolved?
>
> Possible. Yet even then the state of things needs fully writing down, perhaps
> in a commit message for the patch changing the support status. That's likely
> still a time consuming job.
Issue is much of this is better done by the people doing those projects.
Most of what I've done is checking a real hardware/software platform and
confirmed functionality. Presently it boots, but the framebuffer doesn't
work. VMs appear to work fine though.
How does the attached patch look for enabling ACPI?
--
(\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/)
\BS ( | ehem+sig...@m5p.com PGP 87145445 | ) /
\_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
>From 492ea48f537934e7b54de66c5018c349c0123c9a Mon Sep 17 00:00:00 2001
Message-Id: <492ea48f537934e7b54de66c5018c349c0123c9a.1756239431.git.ehem+...@m5p.com>
From: Elliott Mitchell <ehem+...@m5p.com>
Date: Wed, 22 Jul 2020 10:43:57 -0700
Subject: [PATCH] xen/arm: ACPI: Change default configuration
Xen/ARM64 support for ACPI has been mostly implemented. The remaining
issue is handling the IORT table for proper IOMMU support. This means
systems booting with ACPI will not be protected from misbehaving or
misprogrammed hardware. Pass-through of hardware will be unsafe.
Systems without an IOMMU are already unsafe so there is no additional
warning. For such systems defaulting ACPI enabled may allow easier
setup, so change the default.
Presently device-trees are honored before ACPI tables are. This seems
the best default balance right now.
Signed-off-by: Elliott Mitchell <ehem+...@m5p.com>
---
xen/arch/arm/Kconfig | 7 ++++++-
xen/drivers/passthrough/arm/smmu-v3.c | 25 +++++++++++++++++++++++++
2 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 5355534f3d..a420889eb9 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -100,13 +100,18 @@ endchoice
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)"
depends on ARM_64 && ARM_EFI
+ default y
help
Advanced Configuration and Power Interface (ACPI) support for Xen is
an alternative to device tree on ARM64. This requires UEFI.
+ Note this is presently EXPERIMENTAL. If a given device has both
+ device-tree and ACPI support, it is presently (September 2025)
+ recommended to boot using the device-tree.
+
config ARM_EFI
bool "UEFI boot service support"
depends on ARM_64 && !MPU
diff --git a/xen/drivers/passthrough/arm/smmu-v3.c b/xen/drivers/passthrough/arm/smmu-v3.c
index 5e9e3e048e..580da2e210 100644
--- a/xen/drivers/passthrough/arm/smmu-v3.c
+++ b/xen/drivers/passthrough/arm/smmu-v3.c
@@ -82,6 +82,7 @@
#include <xen/linux-compat.h>
#include <xen/list.h>
#include <xen/mm.h>
+#include <xen/param.h>
#include <xen/rbtree.h>
#include <xen/sched.h>
#include <xen/sizes.h>
@@ -2364,6 +2365,9 @@ static int arm_smmu_device_hw_probe(struct arm_smmu_device *smmu)
return 0;
}
+static bool allow_ignore_iort = false;
+boolean_param("allow_ignore_iort", allow_ignore_iort);
+
#ifdef CONFIG_ACPI
static void acpi_smmu_get_options(u32 model, struct arm_smmu_device *smmu)
{
@@ -2386,6 +2390,23 @@ static int arm_smmu_device_acpi_probe(struct platform_device *pdev,
struct device *dev = smmu->dev;
struct acpi_iort_node *node;
+ if (!allow_ignore_iort) {
+ printk(XENLOG_ERR
+"A SMMUv3 is present, but only ACPI support is present in firmware. At this\n"
+"time Xen's ACPI support is incomplete. In particular Xen is unable to make\n"
+"use of IORT tables and is thus unable to make use of IOMMU functionality.\n"
+"Booting in this configuration disables protection against malicious or\n"
+"malfunctioning hardware. This also compromises pass-through of hardware.\n"
+"\n"
+"If you accept the risks of booting without IOMMU support, you can add\n"
+"\"allow_ignore_iort=true\" to Xen's command-line. You are also welcome to\n"
+"sponsor implementing support for IORT tables.\n");
+
+ panic("SMMUv3 is present, but IORT support is incomplete\n");
+ }
+
+ printk(XENLOG_ERR "using incomplete IORT due to command-line param\n");
+
node = *(struct acpi_iort_node **)dev_get_platdata(dev);
/* Retrieve SMMUv3 specific data */
@@ -2402,6 +2423,10 @@ static int arm_smmu_device_acpi_probe(struct platform_device *pdev,
static inline int arm_smmu_device_acpi_probe(struct platform_device *pdev,
struct arm_smmu_device *smmu)
{
+ if (allow_ignore_iort)
+ printk(XENLOG_INFO "allow_ignore_iort has been set, but ACPI "
+ "support is absent\n");
+
return -ENODEV;
}
#endif
--
2.39.5
