Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF


Michael D Kinney
 

Paolo,

The SMBASE register is internal and cannot be directly accessed
by any CPU. There is an SMBASE field that is member of the SMM Save
State area and can only be modified from SMM and requires the
execution of an RSM instruction from SMM for the SMBASE register to
be updated from the current SMBASE field value. The new SMBASE
register value is only used on the next SMI.

https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf

Vol 3C - Section 34.11

The default base address for the SMRAM is 30000H. This value is contained in an internal processor register called
the SMBASE register. The operating system or executive can relocate the SMRAM by setting the SMBASE field in the
saved state map (at offset 7EF8H) to a new value (see Figure 34-4). The RSM instruction reloads the internal
SMBASE register with the value in the SMBASE field each time it exits SMM. All subsequent SMI requests will use
the new SMBASE value to find the starting address for the SMI handler (at SMBASE + 8000H) and the SMRAM state
save area (from SMBASE + FE00H to SMBASE + FFFFH). (The processor resets the value in its internal SMBASE
register to 30000H on a RESET, but does not change it on an INIT.)

One idea to work around these issues is to startup OVMF with the maximum number of
CPUs. All the CPUs will be assigned an SMBASE address and at a safe time to assign
the SMBASE values using the initial 3000:8000 SMI vector because there is a guarantee
of no DMA at that point in the FW init.

Once all the CPUs have been initialized for SMM, the CPUs that are not needed
can be hot removed. As noted above, the SMBASE value does not change on
an INIT. So as long as the hot add operation does not do a RESET, the
SMBASE value must be preserved.

Of course, this is not a good idea from a boot performance perspective,
especially if the max CPUs is a large value.

Another idea is to emulate this behavior. If the hot plug controller
provide registers (only accessible from SMM) to assign the SMBASE address
for every CPU. When a CPU is hot added, QEMU can set the internal SMBASE
register value from the hot plug controller register value. If the SMM
Monarch sends an INIT or an SMI from the Local APIC to the hot added CPU,
then the SMBASE register should not be modified and the CPU starts execution
within TSEG the first time it receives an SMI.

Jiewen and I can collect specific questions on this topic and continue
the discussion here. For example, I do not think there is any method
other than what I referenced above to program the SMBASE register, but
I can ask if there are any other methods.

Thanks,

Mike

-----Original Message-----
From: Paolo Bonzini [mailto:pbonzini@redhat.com]
Sent: Thursday, August 22, 2019 11:43 AM
To: Laszlo Ersek <lersek@redhat.com>; Kinney, Michael D
<michael.d.kinney@intel.com>; rfc@edk2.groups.io; Yao,
Jiewen <jiewen.yao@intel.com>
Cc: Alex Williamson <alex.williamson@redhat.com>;
devel@edk2.groups.io; qemu devel list <qemu-
devel@nongnu.org>; Igor Mammedov <imammedo@redhat.com>;
Chen, Yingwen <yingwen.chen@intel.com>; Nakajima, Jun
<jun.nakajima@intel.com>; Boris Ostrovsky
<boris.ostrovsky@oracle.com>; Joao Marcal Lemos Martins
<joao.m.martins@oracle.com>; Phillip Goerl
<phillip.goerl@oracle.com>
Subject: Re: [edk2-rfc] [edk2-devel] CPU hotplug using
SMM with QEMU+OVMF

On 22/08/19 19:59, Laszlo Ersek wrote:
The firmware and QEMU could agree on a formula, which
would compute
the CPU-specific SMBASE from a value pre-programmed by
the firmware,
and the initial APIC ID of the hot-added CPU.

Yes, it would duplicate code -- the calculation --
between QEMU and
edk2. While that's not optimal, it wouldn't be a first.
No, that would be unmaintainable. The best solution to
me seems to be to make SMBASE programmable from non-SMM
code if some special conditions hold. Michael, would it
be possible to get in contact with the Intel architects?

Paolo

Join rfc@edk2.groups.io to automatically receive all group messages.