All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: pbonzini@redhat.com, philmd@redhat.com, qemu-devel@nongnu.org,
	mst@redhat.com
Subject: Re: [PATCH for-5.0 7/8] acpi: cpuhp: add CPHP_GET_CPU_ID_CMD command
Date: Fri, 6 Dec 2019 16:15:40 +0100	[thread overview]
Message-ID: <20191206161540.1664aace@redhat.com> (raw)
In-Reply-To: <34d3e078-f4e5-149e-a8ef-798d524f53a5@redhat.com>

On Thu, 5 Dec 2019 14:03:01 +0100
Laszlo Ersek <lersek@redhat.com> wrote:

> On 12/04/19 18:05, Igor Mammedov wrote:
> > Extend CPU hotplug interface to return architecture specific
> > identifier for current CPU in 2 registers:
> >  - lower 32 bits existing ACPI_CPU_CMD_DATA_OFFSET_RW
> >  - upper 32 bits in new ACPI_CPU_CMD_DATA2_OFFSET_R at
> >    offset 0.  
> 
> OK.
> 
> > Target user is UEFI firmware, which needs a way to enumerate
> > all CPUs (including possible CPUs) to allocate and initialize
> > CPU structures on boot.  
> 
> (1) This is correct in general, but if we want to keep this description,
> then it should be moved to the commit message of the previous patch.
> CPHP_GET_CPU_ID_CMD is not needed for the purpose described above -- it
> will be necessary for handling the hotplug SMI.
> 
> For the boot time allocation / initialization, the "enumerating present
> and possible CPUs" workflow is necessary, and that is documented in the
> previous patch in this series.
> 
> So if we want to keep this paragraph, we should move it to the previous
> patch's commit message.
> 
> > (for x86: it needs APIC ID and later command will be used to
> > retrieve ARM's MPIDR which serves the similar to APIC ID purpose)  
> 
> (2) I would suggest some punctuation, to make this clearer. How about:
> 
> > On x86, guest UEFI firmware will use CPHP_GET_CPU_ID_CMD for fetching
> > the APIC ID when handling the hotplug SMI.
> >
> > Later, CPHP_GET_CPU_ID_CMD will be used on ARM to retrieve MPIDR,
> > which serves a purpose similar to the x86 APIC ID.

How about following commit message:

    Firmware can enumerate present at boot APs by broadcasting wakeup IPI,
    so that woken up secondary CPUs could register them-selves.
    However in CPU hotplug case, it would need to know architecture
    specific CPU IDs for possible and hotplugged CPUs so it could
    prepare enviroment for and wake hotplugged AP.
    
    Reuse and extend existing CPU hotplug interface to return architecture
    specific ID for currently selected CPU in 2 registers:
     - lower 32 bits in ACPI_CPU_CMD_DATA_OFFSET_RW
     - upper 32 bits in ACPI_CPU_CMD_DATA2_OFFSET_R
    
    On x86, firmware will use CPHP_GET_CPU_ID_CMD for fetching the APIC ID
    when handling hotplug SMI.
    
    Later, CPHP_GET_CPU_ID_CMD will be used on ARM to retrieve MPIDR,
    which serves the similar to APIC ID purpose.

[...]



  reply	other threads:[~2019-12-06 16:34 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-04 17:05 [PATCH for-5.0 0/8] q35: CPU hotplug with secure boot, part 1+2 Igor Mammedov
2019-12-04 17:05 ` [PATCH for-5.0 1/8] q35: implement 128K SMRAM at default SMBASE address Igor Mammedov
2019-12-05 10:43   ` Laszlo Ersek
2019-12-04 17:05 ` [PATCH for-5.0 2/8] tests: q35: MCH: add default SMBASE SMRAM lock test Igor Mammedov
2019-12-04 17:05 ` [PATCH for-5.0 3/8] acpi: cpuhp: spec: clarify 'CPU selector' register usage and endianness Igor Mammedov
2019-12-05 11:50   ` Laszlo Ersek
2019-12-04 17:05 ` [PATCH for-5.0 4/8] acpi: cpuhp: spec: fix 'Command data' description Igor Mammedov
2019-12-05 12:17   ` Laszlo Ersek
2019-12-06 11:09     ` Igor Mammedov
2019-12-06 12:00       ` Laszlo Ersek
2019-12-04 17:05 ` [PATCH for-5.0 5/8] acpi: cpuhp: spec: clarify store into 'Command data' when 'Command field' == 0 Igor Mammedov
2019-12-05 12:21   ` Laszlo Ersek
2019-12-04 17:05 ` [PATCH for-5.0 6/8] acpi: cpuhp: spec: add typical usecases Igor Mammedov
2019-12-05 12:29   ` Laszlo Ersek
2019-12-04 17:05 ` [PATCH for-5.0 7/8] acpi: cpuhp: add CPHP_GET_CPU_ID_CMD command Igor Mammedov
2019-12-05 13:03   ` Laszlo Ersek
2019-12-06 15:15     ` Igor Mammedov [this message]
2019-12-06 15:46       ` Laszlo Ersek
2019-12-04 17:05 ` [PATCH for-5.0 8/8] acpi: cpuhp: spec: document procedure for enabling modern CPU hotplug Igor Mammedov
2019-12-05 14:07   ` Laszlo Ersek
2019-12-06 10:40     ` Igor Mammedov
2019-12-06 12:02       ` Laszlo Ersek
2019-12-06 13:49     ` Igor Mammedov
2019-12-06 15:06       ` Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191206161540.1664aace@redhat.com \
    --to=imammedo@redhat.com \
    --cc=lersek@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.