Re: [PATCH v6 9/9] OvmfPkg/SmmControl2Dxe: negotiate CPU hot-unplug

["Laszlo Ersek" <lersek@redhat.com>]

On 02/03/21 06:46, Ankur Arora wrote:
> On 2021-02-01 9:37 a.m., Laszlo Ersek wrote:

>> (6) Please drop this hunk. We don't try to be smarter than QEMU, in
>> general, whenever we perform feature negotiation.
> 
> Also, AFAICS, we will do the hotplug (and now hot-unplug) even if it wasn't
> negotiated?

Yes, totally. We don't try to "evict" CpuHotplugSmm in case the related
features are not supported/offered by QEMU, we'll just leave
CpuHotplugSmm unused.

Here's why: the SMI feature negotiation interface is locked down at a
certain point; the negotiation of all of the feature bits needs to
happen centrally, in a common spot; and it would require a really quirky
solution in the firmware to let independent drivers negotiate *subsets*
of the features.

You have correctly determined that SmmControl2Dxe, the runtime DXE
driver that produces EFI_SMM_CONTROL2_PROTOCOL, has nothing much to do
with CPU hot-(un)plug. It's just that this is the driver that first
used, and therefore now *owns*, the SMI feature negotiation. (See commit
5ba203b54e59 ("OvmfPkg/SmmControl2Dxe: negotiate
ICH9_LPC_SMI_F_CPU_HOTPLUG", 2020-08-24).)

So, to reformulate your question/statement: the firmware will retain the
ability to do hot-(un)plug even if QEMU doesn't contain (or enable)
those particular features.

Thanks
Laszlo