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

Michael D Kinney


It makes sense to match real HW. That puts us back to
the reset vector and handling the initial SMI at
3000:8000. That is all workable from a FW implementation
perspective. It look like the only issue left is DMA.

DMA protection of memory ranges is a chipset feature.
For the current QEMU implementation, what ranges of
memory are guaranteed to be protected from DMA? Is
it only A/B seg and TSEG?



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

On 21/08/19 19:25, Kinney, Michael D wrote:
Could we have an initial SMBASE that is within TSEG.

If we bring in hot plug CPUs one at a time, then
initial SMBASE in
TSEG can reprogram the SMBASE to the correct value for
that CPU.

Can we add a register to the hot plug controller that
allows the BSP
to set the initial SMBASE value for a hot added CPU?
The default can
be 3000:8000 for compatibility.

Another idea is when the SMI handler runs for a hot
add CPU event, the
SMM monarch programs the hot plug controller register
with the SMBASE
to use for the CPU that is being added. As each CPU
is added, a
different SMBASE value can be programmed by the SMM

Yes, all of these would work. Again, I'm interested in
having something that has a hope of being implemented in
real hardware.

Another, far easier to implement possibility could be a
lockable MSR (could be the existing
MSR_SMM_FEATURE_CONTROL) that allows programming the
SMBASE outside SMM. It would be nice if such a bit
could be defined by Intel.


Join to automatically receive all group messages.