Re: [edk2-devel] [PATCH wave 1 00/10] support QEMU's "SMRAM at default SMBASE" feature

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

On 10/04/19 16:09, Igor Mammedov wrote:
> On Tue, 1 Oct 2019 17:31:17 +0200
> "Laszlo Ersek" <lersek@redhat.com> wrote:

>> (It does not matter if another hotplug CPU starts the relocation in SMM
>> while the earlier one is left with *only* the RSM instruction in SMM,
>> immediately after the swap-back.)
> I don't see why it doesn't matter, let me illustrate the case
> I'm talking about.

Right, I'm sorry -- I completely forgot that the RSM instruction is what
makes the newly set SMBASE permanent!

[...]

> Safest way to deal with it would be:
> 
>   1. wait till all host CPUs are brought into SMM (with hotplug SMI handler = check me in)
> 
>   2. wait till all hotplugged CPUs are put in well know state
>     (a host cpu should send INIT-SIPI-SIPI with NOP vector to wake up)
> 
>   3. a host CPU will serialize hotplugged CPUs relocation by sending
>      uincast SMI + INIT-SIPI-SIPI NOP vector to wake up the second time
>      (with hotplug SMI handler = relocate_me)
> 
> alternatively we could skip step 3 and do following:
> 
>  hotplug_SMI_handler()   
>      hp_cpu_check_in_map[apic_id] = 1;
>      /* wait till another cpu tells me to continue */
>      while(hp_cpu_check_in_map[apic_id]) ;;
>      ...
> 
>  host_cpu_hotplug_all_cpus()
>      wait till all hotpluged CPUs are in hp_cpu_check_in_map;
>      for(i=0;;) {
>         if (hp_cpu_check_in_map[i]) {
>             /* relocate this CPU */
>             hp_cpu_check_in_map[i] = 0;
>         }
> 
>         tell QEMU that FW pulled the CPU in;
>         /* we can add a flag to QEMU's cpu hotplug MMIO interface to FW do it,
>            so that legitimate  GPE handler would tell OS to online only
>            firmware vetted CPUs */
>      }

[...]

>> How can we discover in the hotplug initial SMI handler at 0x3_0000 that
>> the CPU executing the code should have been relocated *earlier*, and the
>> OS just didn't obey the ACPI GPE code? I think a platform reset would be
>> a proper response, but I don't know how to tell, "this CPU should not be
>> here".
> 
> one can ask QEMU about present CPUs (via cpu hotplug interface)
> and compare with present CPU state in FW (OS can hide insert
> event there but not the presence).
> 
> another way is to keep it pinned in relocation SMI handler
> until another CPU tells it to continue with relocation.
> 
> In absence of SMI, such CPU will continue to run wild but do we
> really care about it?

Thanks.

It's clear that, for me, too much hangs in the air right now. I'll have
to get my hands dirty and experiment. I need to learn a lot about this
area of edk2 as well, and experimenting looks like one way.

Let's return to these question once we reach the following state:

- ACPI code generated by QEMU raises a broadcast SMI on VCPU hotplug
- in OVMF, a cold-plugged CPU executes platform code, in a custom SMI
handler
- in OVMF, a hot-plugged CPU executes platform code, in the initial
(default) SMI handler.

Once we get to that point, we can look into further details.

I'll answer under your other email too:
<http://mid.mail-archive.com/20191004133052.20373155@redhat.com>.

Thanks
Laszlo