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

Michael D Kinney


It is my understanding that real HW hot plug uses the SDM defined
methods. Meaning the initial SMI is to 3000:8000 and they rebase
to TSEG in the first SMI. They must have chipset specific methods
to protect 3000:8000 from DMA.

Can we add a chipset feature to prevent DMA to 64KB range from
0x30000-0x3FFFF and the UEFI Memory Map and ACPI content can be
updated so the Guest OS knows to not use that range for DMA?



-----Original Message-----
From: Paolo Bonzini []
Sent: Thursday, August 22, 2019 3:18 PM
To: Kinney, Michael D <>;
Laszlo Ersek <>;;
Yao, Jiewen <>
Cc: Alex Williamson <>;; qemu devel list <qemu->; Igor Mammedov <>;
Chen, Yingwen <>; Nakajima, Jun
<>; Boris Ostrovsky
<>; Joao Marcal Lemos Martins
<>; Phillip Goerl
Subject: Re: [edk2-rfc] [edk2-devel] CPU hotplug using

On 22/08/19 22:06, Kinney, Michael D wrote:
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.
Actually there is also an SMBASE MSR, even though in
current silicon it's read-only and its use is
theoretically limited to SMM-transfer monitors. If that
MSR could be made accessible somehow outside SMM, that
would be great.

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.
IIRC, hot-remove + hot-add will unplugs/plugs a
completely different CPU.

Another idea is to emulate this behavior. If the hot
plug controller
provide registers (only accessible from SMM) to assign
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.

Yes, this would work. But again---if the issue is real
on current hardware too, I'd rather have a matching
solution for virtual platforms.

If the current hardware for example remembers INIT-
preserved across hot-remove/hot-add, we could emulate

I guess the fundamental question is: how do bare metal
platforms avoid this issue, or plan to avoid this issue?
Once we know that, we can use that information to find a
way to implement it in KVM. Only if it is impossible
we'll have a different strategy that is specific to our


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.

Join to automatically receive all group messages.