summaryrefslogtreecommitdiffstats
path: root/docs/specs/acpi_cpu_hotplug.txt
Commit message (Collapse)AuthorAgeFilesLines
* acpi: cpuhp: introduce 'firmware performs eject' status/control bitsIgor Mammedov2020-12-091-5/+14
| | | | | | | | | | | | | Adds bit #4 to status/control field of CPU hotplug MMIO interface. New bit will be used OSPM to mark CPUs as pending for removal by firmware, when it calls _EJ0 method on CPU device node. Later on, when firmware sees this bit set, it will perform CPU eject which will clear bit #4 as well. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20201207140739.3829993-3-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* acpi: cpuhp: document CPHP_GET_CPU_ID_CMD commandIgor Mammedov2020-02-271-0/+2
| | | | | | | | | | | | | Commit 3a61c8db9d25 introduced CPHP_GET_CPU_ID_CMD command but did not sufficiently describe it. Fix it by adding missing command documentation. Fixes: 3a61c8db9d25 ("acpi: cpuhp: add CPHP_GET_CPU_ID_CMD command") Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <1580306781-228371-1-git-send-email-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* acpi: cpuhp: add CPHP_GET_CPU_ID_CMD commandIgor Mammedov2020-01-221-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | 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 environment 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. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <1575896942-331151-10-git-send-email-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* acpi: cpuhp: spec: add typical usecasesIgor Mammedov2020-01-221-3/+48
| | | | | | | | | | | | | Document work-flows for * enabling/detecting modern CPU hotplug interface * finding a CPU with pending 'insert/remove' event * enumerating present and possible CPUs Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <1575896942-331151-9-git-send-email-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* acpi: cpuhp: introduce 'Command data 2' fieldIgor Mammedov2020-01-221-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | No functional change in practice, patch only aims to properly document (in spec and code) intended usage of the reserved space. The new field is to be used for 2 purposes: - detection of modern CPU hotplug interface using CPHP_GET_NEXT_CPU_WITH_EVENT_CMD command. procedure will be described in follow up patch: "acpi: cpuhp: spec: add typical usecases" - for returning upper 32 bits of architecture specific CPU ID, for new CPHP_GET_CPU_ID_CMD command added by follow up patch: "acpi: cpuhp: add CPHP_GET_CPU_ID_CMD command" Change is backward compatible with 4.2 and older machines, as field was unconditionally reserved and always returned 0x0 if modern CPU hotplug interface was enabled. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <1575896942-331151-8-git-send-email-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* acpi: cpuhp: spec: clarify store into 'Command data' when 'Command field' == 0Igor Mammedov2020-01-221-2/+1Star
| | | | | | | | | | | | | Write section of 'Command data' register should describe what happens when it's written into. Correct description in case the last stored 'Command field' value is equal to 0, to reflect that currently it's not supported. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <1575896942-331151-7-git-send-email-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* acpi: cpuhp: spec: fix 'Command data' descriptionIgor Mammedov2020-01-221-6/+5Star
| | | | | | | | | | | | | | Correct returned value description in case 'Command field' == 0x0, it's not PXM but CPU selector value with pending event In addition describe 0 blanket value in case of not supported 'Command field' value. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <1575896942-331151-6-git-send-email-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* acpi: cpuhp: spec: clarify 'CPU selector' register usage and endiannessIgor Mammedov2020-01-221-6/+12
| | | | | | | | | | | | | | * Move reserved registers to the top of the section, so reader would be aware of effects when reading registers description. * State registers endianness explicitly at the beginning of the section * Describe registers behavior in case of 'CPU selector' register contains value that doesn't point to a possible CPU. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <1575896942-331151-5-git-send-email-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* docs: update ACPI CPU hotplug spec with new protocolIgor Mammedov2016-06-241-12/+82
| | | | | | | | | | | | | | | | | | | | Add description of new CPU hotplug interface. To switch from from legacy mode into new mode use fact that write accesses into CPU present bitmap were never used before and were ignored by QEMU. So use it to as a way to switch from legacy mode. That way pc/q35 machine starts in legacy mode and QEMU generated ACPI tables will switch to new CPU hotplug interface during runtime. In case QEMU is started with legacy BIOS (that doesn't support QEMU generated ACPI tables), legacy CPU hotplug will remain active and could be used by BIOS built in ACPI tables for CPU hotplug. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* acpi: ich9: add CPU hotplug handling to Q35 machineIgor Mammedov2014-01-261-1/+3
| | | | | | | | .. use IO port 0cd8-0xcf7 range for CPU present bitmap Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* docs: Fix IO port number for CPU present bitmap.Anthony PERARD2013-09-201-1/+1
| | | | | | Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewd-By: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
* acpi_piix4: Add infrastructure to send CPU hot-plug GPE to guestIgor Mammedov2013-05-011-0/+22
* introduce processor status bitmask visible to guest at 0xaf00 addr, where ACPI asl code expects it * set bit corresponding to APIC ID in processor status bitmask on receiving CPU hot-plug notification * trigger CPU hot-plug SCI, to notify guest about CPU hot-plug event Signed-off-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Andreas Färber <afaerber@suse.de>