linux-kernel - RE: [RFC PATCH v2 27/35] ACPICA: Add new MADT GICC flags fields [code first?]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e91f1c42c6b643a4a8227d1bac895747@huawei.com>
Date:   Fri, 15 Sep 2023 09:21:42 +0000
From:   Salil Mehta <salil.mehta@...wei.com>
To:     Russell King <linux@...linux.org.uk>
CC:     Ard Biesheuvel <ardb@...nel.org>,
        Jonathan Cameron <jonathan.cameron@...wei.com>,
        James Morse <james.morse@....com>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "loongarch@...ts.linux.dev" <loongarch@...ts.linux.dev>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
        "kvmarm@...ts.linux.dev" <kvmarm@...ts.linux.dev>,
        "x86@...nel.org" <x86@...nel.org>,
        "Jean-Philippe Brucker" <jean-philippe@...aro.org>,
        "jianyong.wu@....com" <jianyong.wu@....com>,
        "justin.he@....com" <justin.he@....com>
Subject: RE: [RFC PATCH v2 27/35] ACPICA: Add new MADT GICC flags fields [code
 first?]

Hi Russel,

> From: Russell King <linux@...linux.org.uk>
> Sent: Friday, September 15, 2023 8:09 AM
> To: Salil Mehta <salil.mehta@...wei.com>
> Cc: Ard Biesheuvel <ardb@...nel.org>; Jonathan Cameron
> <jonathan.cameron@...wei.com>; James Morse <james.morse@....com>; linux-
> pm@...r.kernel.org; loongarch@...ts.linux.dev; linux-acpi@...r.kernel.org;
> linux-arch@...r.kernel.org; linux-kernel@...r.kernel.org; linux-arm-
> kernel@...ts.infradead.org; linux-riscv@...ts.infradead.org;
> kvmarm@...ts.linux.dev; x86@...nel.org; Jean-Philippe Brucker <jean-
> philippe@...aro.org>; jianyong.wu@....com; justin.he@....com
> Subject: Re: [RFC PATCH v2 27/35] ACPICA: Add new MADT GICC flags fields
> [code first?]
> 
> On Fri, Sep 15, 2023 at 02:29:13AM +0000, Salil Mehta wrote:
> > On x86, during init, if the MADT entry for LAPIC is found to be
> > online-capable and is enabled as well then possible and present
> 
> Note that the ACPI spec says enabled + online-capable isn't defined.
> 
> "The information conveyed by this bit depends on the value of the
> Enabled bit. If the Enabled bit is set, this bit is reserved and
> must be zero."
> 
> So, if x86 is doing something with the enabled && online-capable
> state (other than ignoring the online-capable) then technically it
> is doing something that the spec doesn't define - and it's
> completely fine if aarch64 does something else (maybe treating it
> strictly as per the spec and ignoring online-capable.)


I would suggest that we should concentrate on what is actually
required. The fact of the matter is there is no need to keep
ACPI MADT.GICC.Enabled and ACPI MADT.GICC.online-capable bits
mutually exclusive. (please correct my understanding here
if I am wrong here)

It is a different matter that x86 has implemented above
requirement first for their x2APIC and spec are still not
reflecting what has been implemented as part of the code.
(I would add, for whatever reasons)

On ARM we have copied something from x86 ACPI Specification
which has not been updated yet. (why it is not updated? Maybe
x86 folks can clarify more on this?). Even on ARM, mutual
exclusiveness of the bits is not required. But does it breaks
anything on ARM to *not* have mutual exclusiveness. 
AFAICS, no, but ARM Arch guys can confirm this?)

If bits are *not* required to be mutually exclusive on either
platforms x86/ARM then, I think, it makes sense to update
ACPI specification for both of the platforms.


Thanks
Salil.