Re: [PATCH for-5.0 8/8] acpi: cpuhp: spec: document procedure for enabling modern CPU hotplug

[Igor Mammedov]

On Thu, 5 Dec 2019 15:07:53 +0100
Laszlo Ersek <address@hidden> wrote:

> On 12/04/19 18:05, Igor Mammedov wrote:
> > Describe how to enable and detect modern CPU hotplug interface.
> > Detection part is based on new CPHP_GET_CPU_ID_CMD command,
> > introduced by "acpi: cpuhp: add CPHP_GET_CPU_ID_CMD command" patch.
> >
> > Signed-off-by: Igor Mammedov <address@hidden>
> > ---
> >  docs/specs/acpi_cpu_hotplug.txt | 22 ++++++++++++++++++++--
> >  1 file changed, 20 insertions(+), 2 deletions(-)  
> 
> Could we make this usecase / workflow independent of the new
> CPHP_GET_CPU_ID_CMD command please?
> 
> I'd like to suggest the following:
> 
> > diff --git a/docs/specs/acpi_cpu_hotplug.txt 
> > b/docs/specs/acpi_cpu_hotplug.txt
> > index bb33144..667b264 100644
> > --- a/docs/specs/acpi_cpu_hotplug.txt
> > +++ b/docs/specs/acpi_cpu_hotplug.txt
> > @@ -15,14 +15,14 @@ CPU present bitmap for:
> >    PIIX-PM  (IO port 0xaf00-0xaf1f, 1-byte access)
> >    One bit per CPU. Bit position reflects corresponding CPU APIC ID. 
> > Read-only.
> >    The first DWORD in bitmap is used in write mode to switch from legacy
> > -  to new CPU hotplug interface, write 0 into it to do switch.
> > +  to modern CPU hotplug interface, write 0 into it to do switch.
> >  ---------------------------------------------------------------
> >  QEMU sets corresponding CPU bit on hot-add event and issues SCI
> >  with GPE.2 event set. CPU present map is read by ACPI BIOS GPE.2 handler
> >  to notify OS about CPU hot-add events. CPU hot-remove isn't supported.
> >
> >  =====================================
> > -ACPI CPU hotplug interface registers:
> > +Modern ACPI CPU hotplug interface registers:
> >  -------------------------------------
> >  Register block base address:
> >      ICH9-LPC IO port 0x0cd8
> > @@ -105,6 +105,24 @@ write access:
> >                other values: reserved
> >
> >      Typical usecases:
> > +        - (x86) Detecting and enabling modern CPU hotplug interface.  
> 
> (1) I think we can drop the (x86) restriction. (Because, we don't need
> to depend on APIC ID specifics; see below.)
I'd rather keep it x86 specific, as enabling interface and talking about
legacy bitmap applies only to x86 impl.
ARM one won't have any of it, it will just be enabled in a future QEMU
(probably even without version-ed machine type).
So could we just say usual "use firmware X.Y with QEMU Z to use CPU hotplug"
in that case?
Do we really need it to be arch agnostic?