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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <cec8f4ad16434c2daa0b5db7f6d60a6b@huawei.com>
Date:   Fri, 15 Sep 2023 14:49:41 +0000
From:   Salil Mehta <salil.mehta@...wei.com>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
CC:     "Russell King (Oracle)" <linux@...linux.org.uk>,
        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?]

> From: Rafael J. Wysocki <rafael@...nel.org>
> Sent: Friday, September 15, 2023 11:21 AM
> To: Salil Mehta <salil.mehta@...wei.com>
> Cc: Rafael J. Wysocki <rafael@...nel.org>; Russell King (Oracle)
> <linux@...linux.org.uk>; 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 11:34 AM Salil Mehta <salil.mehta@...wei.com>
> wrote:
> >
> >
> > > From: Rafael J. Wysocki <rafael@...nel.org>
> > > Sent: Friday, September 15, 2023 9:45 AM
> > > To: Russell King (Oracle) <linux@...linux.org.uk>
> > > Cc: Salil Mehta <salil.mehta@...wei.com>; 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 9:09 AM Russell King (Oracle)
> > > <linux@...linux.org.uk> wrote:
> > > >
> > > > 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 so it is wrong.
> >
> >
> > Or maybe, specification has not been updated yet. code-first?
> 
> Well, if you are aware of any change requests related to this and
> posted as code-first, please let me know.

I am not aware of any on x86. Maybe we can do it on ARM first and
let other Arch pitch-in their objection later? Afterall, there is
a legitimate use-case in case of ARM. Having mutually exclusive
bits breaks certain use-cases and we have to do the tradeoffs. 

This can be done in parallel while other patches are getting
reviewed and momentarily living with the tradeoffs till
specification is sorted. But of course it depends upon what
other stake holders and most importantly what ARM Arch people
think of it.

Thanks
Salil.