1. Messages
  2. [edk2-devel] CPU hotplug using SMM with QEMU+OVMF

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

Michael D Kinney
 

Hi Jiewen,

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.

For this OVMF use case, is any CPU init required
before the first SMI?

From Paolo's list of steps are steps (8a) and (8b)
really required? Can the SMI monarch use the Local
APIC to send a directed SMI to the hot added CPU?
The SMI monarch needs to know the APIC ID of the
hot added CPU. Do we also need to handle the case
where multiple CPUs are added at once? I think we
would need to serialize the use of 3000:8000 for the
SMM rebase operation on each hot added CPU.

It would be simpler if we can guarantee that only
one CPU can be added or removed at a time and the
complete flow of adding a CPU to SMM and the OS
needs to be completed before another add/remove
event needs to be processed.

Mike

-----Original Message-----
From: Yao, Jiewen
Sent: Thursday, August 22, 2019 10:00 PM
To: Kinney, Michael D <michael.d.kinney@...>;
Paolo Bonzini <pbonzini@...>; Laszlo Ersek
<lersek@...>; rfc@edk2.groups.io
Cc: Alex Williamson <alex.williamson@...>;
devel@edk2.groups.io; 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
<phillip.goerl@...>
Subject: RE: [edk2-rfc] [edk2-devel] CPU hotplug using
SMM with QEMU+OVMF

Thank you Mike!

That is good reference on the real hardware behavior.
(Glad it is public.)

For threat model, the unique part in virtual environment
is temp RAM.
The temp RAM in real platform is per CPU cache, while
the temp RAM in virtual platform is global memory.
That brings one more potential attack surface in virtual
environment, if hot-added CPU need run code with stack
or heap before SMI rebase.

Other threats, such as SMRAM or DMA, are same.

Thank you
Yao Jiewen


-----Original Message-----
From: Kinney, Michael D
Sent: Friday, August 23, 2019 9:03 AM
To: Paolo Bonzini <pbonzini@...>; Laszlo Ersek
<lersek@...>; rfc@edk2.groups.io; Yao, Jiewen
<jiewen.yao@...>; Kinney, Michael D
<michael.d.kinney@...>
Cc: Alex Williamson <alex.williamson@...>;
devel@edk2.groups.io; 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
<phillip.goerl@...>
Subject: RE: [edk2-rfc] [edk2-devel] CPU hotplug using
SMM with
QEMU+OVMF

Paolo,

I find the following links related to the discussions
here along with
one example feature called GENPROTRANGE.

https://csrc.nist.gov/CSRC/media/Presentations/The-
Whole-is-Greater/im
a ges-media/day1_trusted-computing_200-250.pdf
https://cansecwest.com/slides/2017/CSW2017_Cuauhtemoc-
Rene_CPU_Ho
t-Add_flow.pdf
https://www.mouser.com/ds/2/612/5520-5500-chipset-ioh-
datasheet-1131
292.pdf

Best regards,

Mike

-----Original Message-----
From: Paolo Bonzini [mailto:pbonzini@...]
Sent: Thursday, August 22, 2019 4:12 PM
To: Kinney, Michael D <michael.d.kinney@...>;
Laszlo Ersek
<lersek@...>; rfc@edk2.groups.io; Yao, Jiewen
<jiewen.yao@...>
Cc: Alex Williamson <alex.williamson@...>;
devel@edk2.groups.io; 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
<phillip.goerl@...>
Subject: Re: [edk2-rfc] [edk2-devel] CPU hotplug
using SMM with
QEMU+OVMF

On 23/08/19 00:32, Kinney, Michael D wrote:
Paolo,

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.
It would be great if you could check.

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?

If real hardware does it at the chipset level, we
will probably use
Igor's suggestion of aliasing A-seg to 3000:0000.
Before starting
the new CPU, the SMI handler can prepare the SMBASE
relocation
trampoline at
A000:8000 and the hot-plugged CPU will find it at
3000:8000 when it receives the initial SMI. Because
this is backed
by RAM at 0xA0000-0xAFFFF, DMA cannot access it and
would still go
through to RAM at 0x30000.

Paolo
Join rfc@edk2.groups.io to automatically receive all group messages.