Re: CPU hotplug using SMM with QEMU+OVMF
On 08/13/19 16:16, Laszlo Ersek wrote:
Yingwen and Jiewen suggested the following process.- What does "Global SMI disabled by default" mean? In particular, what
is "global" here?
Do you mean that the CPU being hot-plugged should mask (by default)
broadcast SMIs? What about directed SMIs? (An attacker could try that
And what about other processors? (I'd assume step (01)) is not
relevant for other processors, but "global" is quite confusing here.)
- Does this part require a new branch somewhere in the OVMF SEC code?
How do we determine whether the CPU executing SEC is BSP or
- How do we tell the hot-plugged AP where to start execution? (I.e. that
it should execute code at a particular pflash location.)
For example, in MpInitLib, we start a specific AP with INIT-SIPI-SIPI,
where "SIPI" stores the startup address in the "Interrupt Command
Register" (which is memory-mapped in xAPIC mode, and an MSR in x2APIC
mode, apparently). That doesn't apply here -- should QEMU auto-start
the new CPU?
- What memory is used as stack by the new CPU, when it runs code from
QEMU does not emulate CAR (Cache As RAM). The new CPU doesn't have
access to SMRAM. And we cannot use AcpiNVS or Reserved memory, because
a malicious OS could use other CPUs -- or PCI device DMA -- to attack
the stack (unless QEMU forcibly paused other CPUs upon hotplug; I'm
- If an attempt is made to hotplug multiple CPUs in quick succession,
does something serialize those attempts?
Again, stack usage could be a concern, even with Cache-As-RAM --
HyperThreads (logical processors) on a single core don't have
Does CPU hotplug apply only at the socket level? If the CPU is
multi-core, what is responsible for hot-plugging all cores present in
(02) New CPU: (Flash) configure memory control to let it access globalIn QEMU/KVM guests, we don't have to enable memory explicitly, it just
exists and works.
In OVMF X64 SEC, we can't access RAM above 4GB, but that shouldn't be an
issue per se.
(03) New CPU: (Flash) send board message to tell host CPU (GPIO->SCI)Maybe we can simplify this in QEMU by broadcasting an SMI to existent
processors immediately upon plugging the new CPU.
(NOTE: Host CPU can only sendSorry, I don't follow -- what register are we talking about here, and
why is the BSP needed to send anything at all? What "instruction" do you
have in mind?
(04) Host CPU: (OS) get message from board that a new CPU is added.I don't understand the OS involvement here. But, again, perhaps QEMU can
force all existent CPUs into SMM immediately upon adding the new CPU.
(06) Host CPU: (SMM) Save 38000, Update 38000 -- fill simple SMMAha, so this is the SMM-only register you mention in step (03). Is the
register specified in the Intel SDM?
(08) New CPU: (Flash) Get message - Enable SMI.What code does the new CPU execute after it completes step (10)? Does it
(11) Host CPU: (SMM) Restore 38000.These steps (i.e., (06) through (11)) don't appear RAS-specific. The
only platform-specific feature seems to be SMI masking register, which
could be extracted into a new SmmCpuFeaturesLib API.
Thus, would you please consider open sourcing firmware code for steps
(06) through (11)?
Alternatively -- and in particular because the stack for step (01)
concerns me --, we could approach this from a high-level, functional
perspective. The states that really matter are the relocated SMBASE for
the new CPU, and the state of the full system, right at the end of step
When the SMM setup quiesces during normal firmware boot, OVMF could use
existent (finalized) SMBASE infomation to *pre-program* some virtual
QEMU hardware, with such state that would be expected, as "final" state,
of any new hotplugged CPU. Afterwards, if / when the hotplug actually
happens, QEMU could blanket-apply this state to the new CPU, and
broadcast a hardware SMI to all CPUs except the new one.
The hardware SMI should tell the firmware that the rest of the process
-- step (12) below, and onward -- is being requested.
If I understand right, this approach would produce an firmware & system
state that's identical to what's expected right after step (11):
- all SMBASEs relocated
- all preexistent CPUs in SMM
- new CPU halted / blocked from launch
- DRAM at 0x30000 / 0x38000 contains OS-owned data
Is my understanding correct that this is the expected state after step
Three more comments on the "SMBASE pre-config" approach:
- the virtual hardware providing this feature should become locked after
the configuration, until next platform reset
- the pre-config should occur via simple hardware accesses, so that it
can be replayed at S3 resume, i.e. as part of the S3 boot script
- from the pre-configured state, and the APIC ID, QEMU itself could
perhaps calculate the SMI stack location for the new processor.
(12) Host CPU: (SMM) Update located data structure to add the new CPUI commented on EFI_SMM_CPU_SERVICE_PROTOCOL in upon bullet (4) of
Calling EFI_SMM_ADD_PROCESSOR looks justified.
What are some of the other member functions used for? The scary one is
===================== (now, the next SMI will bring all CPU into TSEG)OK... but what component injects that SMI, and when?
(13) New CPU: (Flash) run MRC code, to init its own memory.Why is this needed esp. after step (10)? The new CPU has accessed DRAM
already. And why are we executing code from pflash, rather than from
SMRAM, given that we're past SMBASE relocation?
(14) New CPU: (Flash) Deadloop, and wait for INIT-SIPI-SIPI.I'm confused by these steps. I thought that step (12) would complete the
hotplug, by updating the administrative data structures internally. And
the next SMI -- raised for the usual purposes, such as a software SMI
for variable access -- would be handled like it always is, except it
would also pull the new CPU into SMM too.