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 X-Spam-Level: X-Spam-Status: No, score=-13.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,NICE_REPLY_A,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D0844C4727E for ; Wed, 30 Sep 2020 10:36:24 +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 614FE2064B for ; Wed, 30 Sep 2020 10:36:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=xen.org header.i=@xen.org header.b="JKbaC+y4" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 614FE2064B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=xen.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.539.1770 (Exim 4.92) (envelope-from ) id 1kNZSv-0008AS-9E; Wed, 30 Sep 2020 10:36:05 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 539.1770; Wed, 30 Sep 2020 10:36:05 +0000 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" Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kNZSv-0008AL-6A; Wed, 30 Sep 2020 10:36:05 +0000 Received: by outflank-mailman (input) for mailman id 539; Wed, 30 Sep 2020 10:36:03 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kNZSt-0008AG-8C for xen-devel@lists.xenproject.org; Wed, 30 Sep 2020 10:36:03 +0000 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id ea9b56c0-40dd-4a10-b635-ff90f9ca8159; Wed, 30 Sep 2020 10:36:01 +0000 (UTC) Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kNZSp-00074Z-FX; Wed, 30 Sep 2020 10:35:59 +0000 Received: from [54.239.6.188] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kNZSo-0005vo-8K; Wed, 30 Sep 2020 10:35:58 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kNZSt-0008AG-8C for xen-devel@lists.xenproject.org; Wed, 30 Sep 2020 10:36:03 +0000 X-Inumbo-ID: ea9b56c0-40dd-4a10-b635-ff90f9ca8159 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id ea9b56c0-40dd-4a10-b635-ff90f9ca8159; Wed, 30 Sep 2020 10:36:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=sTkBKPiuxTC3q+YZ5Ojh9Flk9kOMS7pL+eKmNAnOdSw=; b=JKbaC+y4LfwxvLDQraMFRdR0O+ khYdpPNF3w0sssgopF2ReiuN/44JCDkccu6MsFumd54kdEZXDoaysW4kOQEzw6CCXZJ+bTp6iROr3 mI72gMpqV57jJTDHJq8vxHL6J5SFMT5OFMF/Hn1Eh7jb8KHFKyWYCdeT/FQsV92t9oT8=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kNZSp-00074Z-FX; Wed, 30 Sep 2020 10:35:59 +0000 Received: from [54.239.6.188] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kNZSo-0005vo-8K; Wed, 30 Sep 2020 10:35:58 +0000 Subject: Re: [PATCH 0/4] xen/arm: Unbreak ACPI To: =?UTF-8?Q?Andr=c3=a9_Przywara?= , =?UTF-8?Q?Alex_Benn=c3=a9e?= Cc: xen-devel@lists.xenproject.org, masami.hiramatsu@linaro.org, ehem+xen@m5p.com, bertrand.marquis@arm.com, Julien Grall , Stefano Stabellini , Volodymyr Babchuk References: <20200926205542.9261-1-julien@xen.org> <87k0wcppnj.fsf@linaro.org> <5afbce1c-0c45-4b8c-771a-f83b91328e4a@xen.org> <87d024p9tc.fsf@linaro.org> From: Julien Grall Message-ID: <7a9f302f-0a95-77f4-c434-e7afedbb8d39@xen.org> Date: Wed, 30 Sep 2020 11:35:55 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit (Removing the x86 folks from the CC list) Hi André, On 30/09/2020 00:39, André Przywara wrote: > On 29/09/2020 22:11, Alex Bennée wrote: > > Hi, > >> Julien Grall writes: >> >>> Hi Alex, >>> >>> On 29/09/2020 16:29, Alex Bennée wrote: >>>> >>>> Julien Grall writes: >>>> >>>>> From: Julien Grall >>>>> >>>>> Hi all, >>>>> >>>>> Xen on ARM has been broken for quite a while on ACPI systems. This >>>>> series aims to fix it. >>>>> >>>>> Unfortunately I don't have a system with ACPI v6.0 or later (QEMU seems >>>>> to only support 5.1). > > Does QEMU provide ACPI tables? Or is this actually EDK2 generating them? > >> So I did only some light testing. > > So about that v6.0 or later: it seems like the requirement comes from: > commit 1c9bd43019cd "arm/acpi: Parse FADT table and get PSCI flags": > "Since STAO table and the GIC version are introduced by ACPI 6.0, we > will check the version and only parse FADT table with version >= 6.0. If > firmware provides ACPI tables with ACPI version less than 6.0, OS will > be messed up with those information, so disable ACPI if we get an FADT > table with version less than 6.0." > > STAO (and XENV) have indeed been introduced by ACPI v6.0, but those > tables are supposed to be *generated* by Xen and handed down to Dom0, > they will never be provided by firmware (or parsed) by the Xen > hypervisor. Checking the Linux code it seems to actually not (yet?) > support the STAO named list, I may be because we don't yet use the named list in Xen. I am not sure if other hypervisor ever used the STAO. > and currently finds and uses the STAO (UART > block bit) regardless of the FADT version number. IIRC, the concern at the time is an OS may decide to bail out if it finds a table that is not meant to exist. > I can't find anything GIC related in the FADT, the whole GIC information > is described in MADT. My memory is quite fuzzy... IIRC the problem is (was?) related to how Linux used to check the size of the MADT. Before commit [1], Linux was checking that the MADT entry was matching the ACPI version. As Xen generates the MADT using the ACPI 6.0 layout, it wouldn't be possible to boot Linux. > > Linux/arm64 seems to be happy with ACPI >= v5.1: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/kernel/acpi.c#n148 > > So can we relax the v6.0 requirement, to be actually >= v5.1? That is > among the first to support ARM anyway, IIRC. I remember trying to relax the requiring in the past. However, I can't remember why I didn't upstream it. There was possibly some issues I could not get around? I think supporting ACPI 5.1 would be useful. So I would suggest to attempt it again and see what breaks. Cheers, [1] commit 9eb1c92b47c73249465d388eaa394fe436a3b489 Author: Jeremy Linton Date: Tue Nov 27 17:59:12 2018 +0000 arm64: acpi: Prepare for longer MADTs The BAD_MADT_GICC_ENTRY check is a little too strict because it rejects MADT entries that don't match the currently known lengths. We should remove this restriction to avoid problems if the table length changes. Future code which might depend on additional fields should be written to validate those fields before using them, rather than trying to globally check known MADT version lengths. Link: https://lkml.kernel.org/r/20181012192937.3819951-1-jeremy.linton@arm.com Signed-off-by: Jeremy Linton [lorenzo.pieralisi@arm.com: added MADT macro comments] Signed-off-by: Lorenzo Pieralisi Acked-by: Sudeep Holla Cc: Will Deacon Cc: Catalin Marinas Cc: Al Stone Cc: "Rafael J. Wysocki" Signed-off-by: Will Deacon -- Julien Grall