On 2021-02-03 12:45 p.m., Laszlo Ersek wrote:
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.
Right, I see your point. Firmware doesn't really get to stand on
ceremony when HW asks it to do stuff.
Thanks
Ankur
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
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#71133): https://edk2.groups.io/g/devel/message/71133
Mute This Topic: https://groups.io/mt/80199973/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
