On Tue, Oct 08, 2019 at 08:58:30PM +0200, Laszlo Ersek wrote: > Eduardo, Igor, > > On 10/08/19 12:52, Laszlo Ersek wrote: > > FW_CFG_MAX_CPUS exposes the (exclusive) maximum APIC ID to guest firmware, > > due to historical reasons. That value is not useful to edk2, however. For > > supporting VCPU hotplug, edk2 needs: > > > > - the boot CPU count (already exposed in FW_CFG_NB_CPUS), > > > > - and the maximum foreseen CPU count (tracked in > > "MachineState.smp.max_cpus", but not currently exposed). > > > > Add a new fw-cfg file to expose "max_cpus". > > > > While at it, expose the rest of the topology too (die / core / thread > > counts), because I expect that the VCPU hotplug feature for OVMF will > > ultimately need those too, and the data size is not large. > > In fact, it seems like OVMF will have to synthesize the new > (hot-plugged) VCPU's *APIC-ID* from the following information sources: > > - the topology information described above (die / core / thread counts), and > > - the "modern" CPU hotplug interface (docs/specs/acpi_cpu_hotplug.txt). > > Now, if I understand correctly, the "CPU selector" ([0x0-0x3]) specifies > a CPU *index*. Therefore, in the hotplug SMI handler (running on one of > the pre-existent CPUs), OVMF will have to translate the new CPU's > selector (the new CPU's *index*) to its *APIC-ID*, based on the topology > information (numbers of dies / cores / threads).
I thought we had already fixed all our guest interfaces to make CPU indexes never visible to guests. If it is still visible somewhere, it's a bug we need to fix. -- Eduardo
