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 SMM >> rebase code. >> >> (07) Host CPU: (SMM) Send message to New CPU to Enable SMI. > > Aha, 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. >> >> (09) Host CPU: (SMM) Send SMI to the new CPU only. >> >> (10) New CPU: (SMM) Response first SMI at 38000, and rebase SMBASE to >> TSEG. > > What code does the new CPU execute after it completes step (10)? Does it > halt? > > >> (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 > (11). > > 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 > (11)? Revisiting some of my notes from earlier, such as <https://bugzilla.redhat.com/show_bug.cgi?id=1454803#c46> -- apologies, private BZ... --, we discussed some of this stuff with Mike on the phone in April. 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". Thanks, Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#45571): https://edk2.groups.io/g/devel/message/45571 Mute This Topic: https://groups.io/mt/32852911/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
