bwlp/qemu.git/docs/specs/acpi_cpu_hotplug.txt, branch spice_video_codecs

docs/specs/acpu_cpu_hotplug: Convert to rST

2021-08-26T16:01:59+00:00

Do a basic conversion of the acpi_cpu_hotplug spec document to rST. Signed-off-by: Peter Maydell Reviewed-by: Igor Mammedov Message-id: 20210727170414.3368-2-peter.maydell@linaro.org

acpi: cpuhp: introduce 'firmware performs eject' status/control bits

2020-12-09T18:04:17+00:00

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 Message-Id: <20201207140739.3829993-3-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin

acpi: cpuhp: document CPHP_GET_CPU_ID_CMD command

2020-02-27T08:46:10+00:00

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 Reviewed-by: Laszlo Ersek Message-Id: <1580306781-228371-1-git-send-email-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin

acpi: cpuhp: add CPHP_GET_CPU_ID_CMD command

2020-01-22T05:23:07+00:00

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 Message-Id: <1575896942-331151-10-git-send-email-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin Reviewed-by: Laszlo Ersek

acpi: cpuhp: spec: add typical usecases

2020-01-22T05:23:07+00:00

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 Message-Id: <1575896942-331151-9-git-send-email-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin Reviewed-by: Laszlo Ersek

acpi: cpuhp: introduce 'Command data 2' field

2020-01-22T05:23:07+00:00

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 Message-Id: <1575896942-331151-8-git-send-email-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin Reviewed-by: Laszlo Ersek

acpi: cpuhp: spec: clarify store into 'Command data' when 'Command field' == 0

2020-01-22T05:23:07+00:00

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 Reviewed-by: Laszlo Ersek Message-Id: <1575896942-331151-7-git-send-email-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin

acpi: cpuhp: spec: fix 'Command data' description

2020-01-22T05:23:07+00:00

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 Reviewed-by: Laszlo Ersek Message-Id: <1575896942-331151-6-git-send-email-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin

acpi: cpuhp: spec: clarify 'CPU selector' register usage and endianness

2020-01-22T05:23:07+00:00

* 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 Reviewed-by: Laszlo Ersek Message-Id: <1575896942-331151-5-git-send-email-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin

docs: update ACPI CPU hotplug spec with new protocol

2016-06-24T02:20:22+00:00

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 Reviewed-by: Michael S. Tsirkin Signed-off-by: Michael S. Tsirkin