Hi Salil,
On 9/2/22 10:12, Jonathan Cameron wrote:
On Thu, 1 Sep 2022 21:18:48 +0100 Salil Mehta salil.mehta@huawei.com wrote:
To support virtual CPU hotplug, ACPI has added an 'online capable' bit to the MADT GICC entries. This indicates a disabled CPU entry may not be possible to online via PSCI until firmware has set enabled bit in _STA.
What about the redistributor in the GICC entry? ACPI doesn't want to say. Assume the worst: When a redistributor is described in the GICC entry, but the entry is marked as disabled at boot, assume the redistributor is inaccessible.
The GICv3 driver doesn't support late online of redistributors, so this means the corresponding CPU can't be brought online either. Clear the possible and present bits.
Systems that want CPU hotplug in a VM can ensure their redistributors are always-on, and describe them that way with a GICR entry in the MADT.
When mapping redistributors found via GICC entries, handle the case where the arch code believes the CPU is present and possible, but it does not have an accessible redistributor. Print a warning and clear the present and possible bits.
diff --git a/include/linux/acpi.h b/include/linux/acpi.h index 358d9b971de8..81f5df4a536a 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -269,7 +269,8 @@ void acpi_table_print_madt_entry (struct acpi_subtable_header *madt);
static inline bool acpi_gicc_is_usable(struct acpi_madt_generic_interrupt *gicc) {
- return (gicc->flags & ACPI_MADT_ENABLED);
- return ((gicc->flags & ACPI_MADT_ENABLED ||
gicc->flags & ACPI_MADT_GICC_CPU_CAPABLE));This does not looks right to me.
As per the ACPI specification 6.5 Draft-12Aug2022" "Table 5.37: GICC CPU Interface Flags", below are the possible combinations of the existing "Enabled" Bit with *new* "online-capable" Bit:
Note the ACPI 6.5 specification is public: https://uefi.org/specifications so let's refer to that.
Table 5.37: GICC CPU Interface Flags +---------+---------------------------------------+ | | Enabled Bit(0) | | +-------+---------------+---------------+ | | Bool | False | True | +---------+-------+---------------+---------------+ | | | | | | | False | | | | | | CPU is | CPU is | | | | Not Usable | Ready to Use | | Online | | | | | Capable +-------+---------------+---------------+ | Bit(3) | | | | | | | CPU is | *Invalid* | | | True | Online-Capable| Combination | | | | | | | | | | | +---------+-------+---------------+---------------+Description:
Enabled Bit(0): If this bit is set, the processor is ready for use. If this bit is clear and the Online Capable bit is set, the system supports enabling this processor during OS runtime. If this bit is clear and the Online Capable bit is also clear, this processor is unusable, and the operating system support will not attempt to use it.
Online-capable Bit(3): 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. Otherwise, if this bit is set, the system supports enabling this processor later during OS runtime.
Above check will return "cpu is usable" even for Enabled=true && online-capable=true (INVALID Case)?
Yes. Why should linux sanity check the ACPI tables?
In this case, trying to do this just results in harder to read code. What is the benefit? I very much doubt that combination can be used for anything that implies the CPU can't be used.
Thanks,
James