Xen-Devel Archive on lore.kernel.org
 help / color / Atom feed
From: Julien Grall <julien@xen.org>
To: "André Przywara" <andre.przywara@arm.com>,
	"Alex Bennée" <alex.bennee@linaro.org>
Cc: xen-devel@lists.xenproject.org, masami.hiramatsu@linaro.org,
	ehem+xen@m5p.com, bertrand.marquis@arm.com,
	Julien Grall <jgrall@amazon.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: Re: [PATCH 0/4] xen/arm: Unbreak ACPI
Date: Wed, 30 Sep 2020 11:35:55 +0100
Message-ID: <7a9f302f-0a95-77f4-c434-e7afedbb8d39@xen.org> (raw)
In-Reply-To: <d4f86fcf-fe13-5d96-895f-2737300b6628@arm.com>

(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 <julien@xen.org> writes:
>>
>>> Hi Alex,
>>>
>>> On 29/09/2020 16:29, Alex Bennée wrote:
>>>>
>>>> Julien Grall <julien@xen.org> writes:
>>>>
>>>>> From: Julien Grall <jgrall@amazon.com>
>>>>>
>>>>> 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 <jeremy.linton@arm.com>
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 <jeremy.linton@arm.com>
     [lorenzo.pieralisi@arm.com: added MADT macro comments]
     Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
     Acked-by: Sudeep Holla <sudeep.holla@arm.com>
     Cc: Will Deacon <will.deacon@arm.com>
     Cc: Catalin Marinas <catalin.marinas@arm.com>
     Cc: Al Stone <ahs3@redhat.com>
     Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
     Signed-off-by: Will Deacon <will.deacon@arm.com>

-- 
Julien Grall


  parent reply index

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-26 20:55 Julien Grall
2020-09-26 20:55 ` [PATCH 1/4] xen/acpi: Rework acpi_os_map_memory() and acpi_os_unmap_memory() Julien Grall
2020-09-28  8:18   ` Jan Beulich
2020-09-28  9:58     ` Julien Grall
2020-09-28 10:09       ` Jan Beulich
2020-09-28 10:39         ` Julien Grall
2020-10-10  9:49           ` Julien Grall
2020-10-10 10:04             ` Julien Grall
2020-09-29 11:10   ` Rahul Singh
2020-10-01  0:06   ` Stefano Stabellini
2020-10-01 15:09     ` Julien Grall
2020-09-26 20:55 ` [PATCH 2/4] xen/arm: acpi: The fixmap area should always be cleared during failure/unmap Julien Grall
2020-09-29 11:13   ` Rahul Singh
2020-10-01  0:30   ` Stefano Stabellini
2020-10-01 15:14     ` Julien Grall
2020-09-26 20:55 ` [PATCH 3/4] xen/arm: Check if the platform is not using ACPI before initializing Dom0less Julien Grall
2020-09-29 11:17   ` Rahul Singh
2020-09-30 23:26   ` Stefano Stabellini
2020-09-26 20:55 ` [PATCH 4/4] xen/arm: Introduce fw_unreserved_regions() and use it Julien Grall
2020-09-30 23:40   ` Stefano Stabellini
2020-10-01 15:34     ` Julien Grall
2020-09-27  1:47 ` [PATCH 0/4] xen/arm: Unbreak ACPI Elliott Mitchell
2020-09-29 15:28   ` Elliott Mitchell
2020-09-28  6:47 ` Masami Hiramatsu
2020-09-28 13:00   ` Masami Hiramatsu
2020-10-16 22:33     ` Xen-ARM EFI/ACPI problems (was: Re: [PATCH 0/4] xen/arm: Unbreak ACPI) Elliott Mitchell
2020-10-17  5:12       ` Elliott Mitchell
2020-10-08 18:39   ` [PATCH 0/4] xen/arm: Unbreak ACPI Elliott Mitchell
2020-10-09  9:39     ` Julien Grall
2020-10-09 14:22       ` Elliott Mitchell
2020-10-09 18:15         ` Julien Grall
2020-10-09 22:36           ` Elliott Mitchell
2020-10-09 21:49   ` Elliott Mitchell
2020-10-10 11:02   ` Julien Grall
2020-10-12 19:02     ` Stefano Stabellini
2020-10-12 21:34       ` Elliott Mitchell
2020-10-14  1:06         ` Stefano Stabellini
2020-10-14  1:37           ` Elliott Mitchell
2020-10-14 17:47             ` Julien Grall
2020-10-15 18:00               ` Stefano Stabellini
2020-10-14 17:44       ` Julien Grall
2020-09-29 11:10 ` Rahul Singh
2020-09-29 15:29 ` Alex Bennée
2020-09-29 17:07   ` Julien Grall
2020-09-29 21:11     ` Alex Bennée
2020-09-29 23:39       ` André Przywara
2020-09-30  8:51         ` Alex Bennée
2020-09-30 10:35         ` Julien Grall [this message]
2020-09-30  9:42       ` Julien Grall
2020-09-30 10:38         ` Alex Bennée
2020-09-30 11:10           ` Julien Grall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7a9f302f-0a95-77f4-c434-e7afedbb8d39@xen.org \
    --to=julien@xen.org \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=alex.bennee@linaro.org \
    --cc=andre.przywara@arm.com \
    --cc=bertrand.marquis@arm.com \
    --cc=ehem+xen@m5p.com \
    --cc=jgrall@amazon.com \
    --cc=masami.hiramatsu@linaro.org \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Xen-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/xen-devel/0 xen-devel/git/0.git
	git clone --mirror https://lore.kernel.org/xen-devel/1 xen-devel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 xen-devel xen-devel/ https://lore.kernel.org/xen-devel \
		xen-devel@lists.xenproject.org xen-devel@lists.xen.org
	public-inbox-index xen-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.xenproject.lists.xen-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git