From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 64EBAC433EF for ; Fri, 12 Nov 2021 04:28:53 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0729B60F90 for ; Fri, 12 Nov 2021 04:28:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 0729B60F90 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=m5p.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.224954.388509 (Exim 4.92) (envelope-from ) id 1mlOAb-0003UU-V9; Fri, 12 Nov 2021 04:28:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 224954.388509; Fri, 12 Nov 2021 04:28:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mlOAb-0003UM-PE; Fri, 12 Nov 2021 04:28:09 +0000 Received: by outflank-mailman (input) for mailman id 224954; Fri, 12 Nov 2021 04:28:08 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mlOAa-0003UG-Cm for xen-devel@lists.xenproject.org; Fri, 12 Nov 2021 04:28:08 +0000 Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ed78dfc1-4370-11ec-9787-a32c541c8605; Fri, 12 Nov 2021 05:28:05 +0100 (CET) Received: from m5p.com (mailhost.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:f7]) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPS id 1AC4RrFC074434 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 11 Nov 2021 23:27:58 -0500 (EST) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.16.1/8.15.2/Submit) id 1AC4RqJK074433; Thu, 11 Nov 2021 20:27:52 -0800 (PST) (envelope-from ehem) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ed78dfc1-4370-11ec-9787-a32c541c8605 Date: Thu, 11 Nov 2021 20:27:52 -0800 From: Elliott Mitchell To: Stefano Stabellini , Julien Grall Cc: xen-devel@lists.xenproject.org Subject: ACPI/UEFI support for Xen/ARM status? Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I've been busy with another part of this project, so I've lost track of progress on ACPI/UEFI support on ARM. Last I'd read full support for ACPI/UEFI seemed a ways off. Using a stub domain to constrain ACPI table parsing seemed the favored approach. I was under the impression that would take some time. What is the status? Do the Xen/ARM leads have any guesses for when full ACPI/UEFI support might reach completion? I noticed Linux made full ACPI/UEFI support mandatory for ARM64 before 3.19, so Xen's seems far behind the curve here. While incidents of garbled ACPI tables are notorious, those are notable due to being rare. Whereas I've had terrible luck with device-trees. The instances of any given OS *not* breaking device-trees with even patch-level changes are rare. -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \BS ( | ehem+sigmsg@m5p.com PGP 87145445 | ) / \_CS\ | _____ -O #include O- _____ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445