[RFC PATCH 0/1] ACPI: Fix missing CPU hotplug/hotunplug events with > 255 vCPUs

[Eric Mackay]

ACPI hotplug with 255 or less vCPUs can use the legacy CPU hotplug interface, 
which does
not support hotunplug. If it's available, hotunplug will use the modern CPU 
hotplug interface.
This creates a situation where hotplug and hotunplug are using different 
interfaces, but
the end result is still functional. CPUs can be hotplugged and hotunplugged at 
will.

With > 255 vCPUs, both hotplug and hotunplug will use the modern ACPI interface.
There is no priority or rules of mutual exclusion defined in this interface,
and the behavior in the guest is implementation-defined.

Unfortunately, it is possible to have both a hotplug and hotunplug event pending
for the same vCPU. When the guest processes its pending events, it may see the
hotplug but ignore the hotunplug.

The most recent event is likely to reflect the desired state of the system, so
ignoring the hotunplug event in this scenario is unacceptable.

Repro: This can be seen in practice when a q35 VM is started in qemu, with
maxcpus=260 or something above 255, and a few statically allocated CPUs.
Example smp line: "-smp 4,sockets=2,dies=1,cores=65,threads=2,maxcpus=260"
Then use libvirt to add vCPUs up to the maximum before continuing the VM. After
the guest starts up, delete one of the vCPUs. 'lscpu' in the guest should still
show 260.

The proposed solution is to enforce mutual exclusion between the hotplug and 
hotunplug
bits in the modern ACPI interface. Setting a new pending event will clear a 
previously
pending event of the opposite type, thus preserving only the most recently 
requested
state.

Eric Mackay (1):
  ACPI: Enforce mutual exclusion betwen CPU insertion and removal events

 hw/acpi/cpu.c         | 36 ++++++++++++++++++++++++++++++++----
 include/hw/acpi/cpu.h |  4 ++++
 2 files changed, 36 insertions(+), 4 deletions(-)

-- 
2.43.5