On 08/28/19 14:01, Igor Mammedov wrote:
On Tue, 27 Aug 2019 22:11:15 +0200
Laszlo Ersek <lersek@...> wrote:
On 08/27/19 18:23, Igor Mammedov wrote:from SDM vol 3:
On Mon, 26 Aug 2019 17:30:43 +0200The TSEG base calculation is not trivial in this environment. The 32-bit
Laszlo Ersek <lersek@...> wrote:
On 08/23/19 17:25, Kinney, Michael D wrote:Do we need anything complex in relocation handler, though?
Hi Jiewen,"without a stack" looks very risky to me. Even if we manage to implement
If a hot add CPU needs to run any code before the
first SMI, I would recommend is only executes code
from a write protected FLASH range without a stack
and then wait for the first SMI.
the guest code initially, we'll be trapped without a stack, should we
ever need to add more complex stuff there.
From what I'd imagine, minimum handler should
1: get address of TSEG, possibly read it from chipset
RAM size needs to be read from the CMOS (IO port accesses). Then the
extended TSEG size (if any) needs to be detected from PCI config space
(IO port accesses). Both CMOS and PCI config space requires IO port
writes too (not just reads). Even if there are enough registers for the
calculations, can we rely on these unprotected IO ports?
Also, can we switch to 32-bit mode without a stack? I assume it would be
necessary to switch to 32-bit mode for 32-bit arithmetic.
34.5.1 Initial SMM Execution Environment
After saving the current context of the processor, the processor initializes its core registers to the values shown in Table 34-4. Upon entering SMM, the PE and PG flags in control register CR0 are cleared, which places the processor in an environment similar to real-address mode. The differences between the SMM execution environment and the real-address mode execution environment are as follows:
• The addressable address space ranges from 0 to FFFFFFFFH (4 GBytes).
• The normal 64-KByte segment limit for real-address mode is increased to 4 GBytes.
• The default operand and address sizes are set to 16 bits, which restricts the addressable SMRAM address space to the 1-MByte real-address mode limit for native real-address-mode code. However, operand-size and address-size override prefixes can be used to access the address space beyond
That helps. Thanks for the quote!
Getting the initial APIC ID needs some CPUID instructions IIUC, whichwe could map at 30000 not 64K required for save area but 128K and use
clobber EAX through EDX, if I understand correctly. Given the register
pressure, CPUID might have to be one of the first instructions to call.
2nd half as secure RAM for stack and intermediate data.
Firmware could put there pre-calculated pointer to TSEG after it's configured and locked down,
this way relocation handler won't have to figure out TSEG address on its own.
Sounds like a great idea.
It also could execute INIT reset, which leaves initialized SMM untouched
2: calculate its new SMBASE offset based on its APIC IDI agree about that implication, yes. *If* we send an INIT/SIPI/SIPI to
3: save new SMBASE
07b - implies 08b
For this OVMF use case, is any CPU init requiredI expressed a preference for that too: "I wish we could simply wake the
before the first SMI?
new CPU [...] with an SMI".
From Paolo's list of steps are steps (8a) and (8b)
the new CPU, then the new CPU needs a HLT loop, I think.
but otherwise CPU would be inactive.
Let me prepare a QEMU branch with something usable for you.
8b could be trivial hlt loop and we most likely could skip 08a and signaling host CPU stepsI think we'll need a separate QEMU tree for this. I'm quite in the dark
but we need INIT/SIPI/SIPI sequence to wake up AP so it could handle pending SMI
before handling SIPI (so behavior would follow SDM).
See again my message linked above -- just after the quoted sentence, ISo far we should be able to implement it per spec (at least SDM one),
wrote, "IOW, if we could excise steps 07b, 08a, 08b".
But, I obviously defer to Paolo and Igor on that.
(I do believe we have a dilemma here. In QEMU, we probably prefer to
emulate physical hardware as faithfully as possible. However, we do not
have Cache-As-RAM (nor do we intend to, IIUC). Does that justify other
divergences from physical hardware too, such as waking just by virtue of
but we would still need to invent chipset hardware
i.e. like adding to Q35 non exiting SMRAM and means to map/unmap it
to non-SMM address space.
(and I hope we could avoid adding "parked CPU" thingy)
-- I can't tell if I'll be able to do something in OVMF without actually
trying it. And for that, we'll need some proposed QEMU code that is
testable, but not upstream yet. (As I might realize that I'm unable to
make it work in OVMF.)
To avoid inventing mgmt API for configuring SMRAM at 30000,
I'm suggesting to steal/alias top or bottom 128K of TSEG window to 30000.
This way OVMF would be able to set SMI relocation handler modifying
TSEG and pass TSEG base/other data to it as well.
Would it work for you or should we try more elaborate approach?
I believe this this change may not be cross-compatible between QEMU and
OVMF. OVMF platform code would have to hide the stolen part of the TSEG
from core edk2 SMM code.
If old OVMF were booted on new QEMU, I believe things could break -- the
SMM core would be at liberty to use any part of the TSEG (advertized by
OVMF platform code to the full extent), and the SMM core would continue
expecting 0x30000 to be normal (and distinct) RAM. If QEMU suddenly
aliased both ranges to the same contents (in System Management Mode), I
think that would confuse the SMM core.
We already negotiate (or at least, detect) two features in this area;
"extended TSEG" and "broadcast SMI". I believe we need a CPU hotplug
controller anyway -- is that still the case? If it is, we could use
registers on that device, for managing the alias.
If the default SMBASE area is corrupted due to concurrent access, couldin case of broadcast SMI (btw does OVMF use broadcast SMIs?) several CPUs could end up
that lead to invalid relocated SMBASE values? Possibly pointing into
Broadcast SMI is very important for OVMF.
The Platform Init spec basically defines an abstract interface for
runtime UEFI drivers for submitting an "SMM request". Part of that is
raising an SMI (also abstracted).
*How* an SMI is raised is platform-dependent, and edk2 provides two
implementations for synching APs in SMM (broadcast ("traditional") and
In our testing on QEMU/KVM, the broadcast/traditional sync mode worked
very robustly (with QEMU actually broadcasting the SMI in response to IO
port 0xB2 writes), but the relaxed synch mode was unstable / brittle (in
particular during S3 resume). Therefore broadcast SMI is negotiated by
OVMF whenever it is available -- it makes a big difference in stability.
Now, whether broadcast SMI needs to be part of CPU hotplug specifically,
that's a different question. The CPU hotplug logic may not necessarily
have to go through the same (standardized) interfaces that runtime UEFI
with the same SMBASE within SMRAM
1: default one: in case the 2nd CPU enters SMM after the 1st CPU saved new SMBASE but before it's called RSM
2: duplicated SMBASE: where the 2nd CPU saves its new SMBASE before the 1st calls RSM
while the 2nd could be counteracted with using locks, I don't see how 1st one could be avoided.
May be host CPU can send 2nd SMI so just relocated CPU could send an ACK from relocated SMBASE/with new SMI handler?
I don't have any better idea. We could protect the default SMBASE with a
semaphore (spinlock?) in SMRAM, but that would have to be released with
the owning CPU executing code at the new SMBASE. Basically, what you
say, just "ACK" meaning "release the spinlock".