On 08/13/19 18:09, Laszlo Ersek wrote:
On 08/13/19 16:16, Laszlo Ersek wrote:
(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
(07) Host CPU: (SMM) Send message to New CPU to Enable SMI.
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
(09) Host CPU: (SMM) Send SMI to the new CPU only.
(10) New CPU: (SMM) Response first SMI at 38000, and rebase SMBASE to
(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
Revisiting some of my notes from earlier, such as
> -- apologies,
private BZ... --, we discussed some of this stuff with Mike on the phone
And, it looked like generating a hardware SMI in QEMU, in association
with the hotplug action that was being requested through the QEMU
monitor, would be the right approach.
By now I have forgotten about that discussion -- hence "revisiting my
notes"--, but luckily, it seems consistent with what I've proposed
above, under "alternatively".