Perhaps there is a way to avoid the 3000:8000 startup
toggle quoted messageShow quoted text
If a CPU is added after a cold reset, it is already in a
different state because one of the active CPUs needs to
release it by interacting with the hot plug controller.
Can the SMRR for CPUs in that state be pre-programmed to
match the SMRR in the rest of the active CPUs?
For OVMF we expect all the active CPUs to use the same
SMRR value, so a check can be made to verify that all
the active CPUs have the same SMRR value. If they do,
then any CPU released through the hot plug controller
can have its SMRR pre-programmed and the initial SMI
will start within TSEG.
We just need to decide what to do in the unexpected
case where all the active CPUs do not have the same
This should also reduce the total number of steps.
From: firstname.lastname@example.org [mailto:email@example.com] On
Behalf Of Yao, Jiewen
Sent: Sunday, August 18, 2019 4:01 PM
To: Paolo Bonzini <firstname.lastname@example.org>
Cc: Alex Williamson <email@example.com>; Laszlo
Ersek <firstname.lastname@example.org>; email@example.com; edk2-
rfc-groups-io <firstname.lastname@example.org>; qemu devel list
<email@example.com>; Igor Mammedov
<firstname.lastname@example.org>; Chen, Yingwen
<email@example.com>; Nakajima, Jun
<firstname.lastname@example.org>; Boris Ostrovsky
<email@example.com>; Joao Marcal Lemos Martins
<firstname.lastname@example.org>; Phillip Goerl
Subject: Re: [edk2-rfc] [edk2-devel] CPU hotplug using
SMM with QEMU+OVMF
in real world, we deprecate AB-seg usage because they
are vulnerable to smm cache poison attack.
I assume cache poison is out of scope in the virtual
world, or there is a way to prevent ABseg cache poison.
在 2019年8月19日，上午3:50，Paolo Bonzini<email@example.com> 写道：
On 17/08/19 02:20, Yao, Jiewen wrote:
[Jiewen] That is OK. Then we MUST add the third
device to perform DMA attack in the virtual world.
-- Adversary: Simple hardware attacker, who can use
scope. That is be handled by IOMMU in the real world,
NOTE: The DMA attack in the real world is out of
such as VTd. -- Please do clarify if this is TRUE.
In the real world:
#1: the SMM MUST be non-DMA capable region.
#2: the MMIO MUST be non-DMA capable region.
#3: the stolen memory MIGHT be DMA capable region or
region. It depends upon the silicon design.
#4: the normal OS accessible memory - including ACPI
DMA capable region.
NVS, and reserved memory not included by #3 - MUST be
As such, IOMMU protection is NOT required for #1 and
required for #4.
protection MIGHT be required for #3 and MUST be
same way. Please
I assume the virtual environment is designed in the
correct me if I am wrong.Correct. The 0x30000...0x3ffff area is the only
Igor's idea (or a variant, for example optionallyremapping
0xa0000..0xaffff SMRAM to 0x30000) is becoming moreand more attractive.