toggle quoted messageShow quoted text
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?
From: Paolo Bonzini [mailto:pbonzini@...]
Sent: Wednesday, August 21, 2019 10:40 AM
To: Kinney, Michael D <michael.d.kinney@...>;
firstname.lastname@example.org; Yao, Jiewen <jiewen.yao@...>
Cc: Alex Williamson <alex.williamson@...>; Laszlo
Ersek <lersek@...>; email@example.com; qemu
devel list <qemu-devel@...>; Igor Mammedov
<imammedo@...>; Chen, Yingwen
<yingwen.chen@...>; Nakajima, Jun
<jun.nakajima@...>; Boris Ostrovsky
<boris.ostrovsky@...>; Joao Marcal Lemos Martins
<joao.m.martins@...>; Phillip Goerl
Subject: Re: [edk2-rfc] [edk2-devel] CPU hotplug using
SMM with QEMU+OVMF
On 21/08/19 19:25, Kinney, Michael D wrote:
Could we have an initial SMBASE that is within TSEG.initial SMBASE in
If we bring in hot plug CPUs one at a time, then
TSEG can reprogram the SMBASE to the correct value forthat CPU.
allows the BSP
Can we add a register to the hot plug controller that
to set the initial SMBASE value for a hot added CPU?The default can
be 3000:8000 for compatibility.add CPU event, the
Another idea is when the SMI handler runs for a hot
SMM monarch programs the hot plug controller registerwith the SMBASE
to use for the CPU that is being added. As each CPUis added, a
different SMBASE value can be programmed by the SMMMonarch.
Yes, all of these would work. Again, I'm interested in
having something that has a hope of being implemented in
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.