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

[Salil Mehta]

> From: Rafael J. Wysocki <rafael at kernel.org>
> Sent: Friday, September 15, 2023 9:45 AM
> To: Russell King (Oracle) <linux at armlinux.org.uk>
> Cc: Salil Mehta <salil.mehta at huawei.com>; Ard Biesheuvel <ardb at kernel.org>;
> Jonathan Cameron <jonathan.cameron at huawei.com>; James Morse
> <james.morse at arm.com>; linux-pm at vger.kernel.org; loongarch at lists.linux.dev;
> linux-acpi at vger.kernel.org; linux-arch at vger.kernel.org; linux-
> kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> riscv at lists.infradead.org; kvmarm at lists.linux.dev; x86 at kernel.org; Jean-
> Philippe Brucker <jean-philippe at linaro.org>; jianyong.wu at arm.com;
> justin.he at arm.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 at armlinux.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?


> 
> > - and it's
> > completely fine if aarch64 does something else (maybe treating it
> > strictly as per the spec and ignoring online-capable.)
> 
> That actually is the only compliant thing that can be done.

Yes, but the question is it what is required and does it solves
the problem of Hotplug. I think no. 

By complying with what is there in the spec means we have to
do the tradeoff between having not to support hot(un)plugging
of the cold-plugged CPUs Vs risk of breaking the legacy OS
attempting to use newer platforms with Hotplug support. Later
is more of a ARM problem as we are not allowed to tweak the
ACPI tables once the system has booted.


> 
> As per the spec (quoted above), a platform firmware setting
> online-capable to 1 when Enabled is set is not compliant and it is
> invalid to treat this as meaningful data.

Correct. but is it really what we need? We need both of the
Bits to be set for supporting hot(un)plugging of cold booted
CPUs.


> 
> As currently defined, online-capable is only applicable to CPUs that
> are not enabled to start with and its role is to make it clear whether
> or not they can be enabled later AFAICS.

Correct.

> 
> If there is a need to represent the case in which a CPI that is
> enabled to start with can be disabled, but cannot be enabled again,
> the spec needs to be updated.

Absolutely. And that’s what my humble suggestion is as well.


Thanks
Salil.