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

[Salil Mehta]

Hi Russel,
Thanks for highlighting your concerns.

> From: Russell King <linux at armlinux.org.uk>
> Sent: Friday, September 15, 2023 2:43 PM
> To: Salil Mehta <salil.mehta at huawei.com>
> Cc: Rafael J. Wysocki <rafael at kernel.org>; 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 09:34:46AM +0000, Salil Mehta wrote:
> > > > 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?
> 
> What is the point in speculating. If you want to speculate about it,
> fine, but please don't use speculation as a reason that "oh we need
> to sort this out before we can merge the patches".

[already replied in other thread but repeating it here]

Sorry, I am not aware but I was suggesting this. Can we have this
done for ARM first because there is a legitimate use-case. This
can be done in parallel while other patches are getting reviewed.
It would be great if they get accepted even in the current form.


> This is precisely why engineers are bad at producing products. They
> like to continually tweak the design, and the design never gets out
> the door. You need someone who is a project manager to tell engineers
> when to stop. Without a project manager to do that, eventually the
> project fades into insignificance because it becomes no longer relevant
> or has its funding cut.
> 
> Hotplug VCPU on aarch64 feels exactly like that - it seems to be an
> engineer project that is just going to for-ever rumble on and never
> actually see the light of day.


Sometimes things are not in single persons control. Yes, it is
frustrating, I do understand that.


> So please - stop speculating and lets get vCPU hotplug *actually*
> delivered and usable. Even if it's not 100% perfect.

We need to decide what is the criteria of acceptability and it can
vary across organizations. It depends upon internal requirements.
The issues what I pointed are,

1. Legacy OS will not boot on latest platform with hotplug support.
   - Try running older windows on ARM platform with hotplug support.
     - older windows will only see boot cpu with online-capable bit.
     - Will windows use _OSC to check compatibility?
   - We have verified this with older Linux and it only shows 1 CPU.
2. Hot(un)plug of cold-booted CPUs.  
   - Its use-case is subjective. Maybe you can throw light on this.

With current composition of bits both 1 & 2 cannot be supported
simultaneously. 

It is perfectly okay to live with them while clearly indicating
what we intend to support or are in process of supporting it.
But we do need an open discussion about how to proceed. This is
to avoid surprises later on.

BTW, I am just trying to make every one aware of the problems.

Many thanks!

Best regards
Salil.