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


Michael D Kinney
 

Laszlo,

I believe all the code for the AP startup vector
is already in edk2.

It is a combination of the reset vector code in
UefiCpuPkg/ResetVecor/Vtf0 and an IA32/X64 specific
feature in the GenFv tool. It sets up a 4KB aligned
location near 4GB which can be used to start an AP
using INIT-SIPI-SIPI.

DI is set to 'AP' if the processor is not the BSP.
This can be used to choose to put the APs into a
wait loop executing from the protected FLASH region.

The SMM Monarch on a hot add event can use the Local
APIC to send an INIT-SIPI-SIPI to wake the AP at the 4KB
startup vector in FLASH. Later the SMM Monarch
can sent use the Local APIC to send an SMI to pull the
hot added CPU into SMM. It is not clear if we have to
do both SIPI followed by the SMI or if we can just do
the SMI.

Best regards,

Mike

-----Original Message-----
From: devel@edk2.groups.io
[mailto:devel@edk2.groups.io] On Behalf Of Laszlo Ersek
Sent: Thursday, August 22, 2019 11:29 AM
To: Paolo Bonzini <pbonzini@redhat.com>; Kinney,
Michael D <michael.d.kinney@intel.com>;
rfc@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>
Cc: Alex Williamson <alex.williamson@redhat.com>;
devel@edk2.groups.io; qemu devel list <qemu-
devel@nongnu.org>; Igor Mammedov <imammedo@redhat.com>;
Chen, Yingwen <yingwen.chen@intel.com>; Nakajima, Jun
<jun.nakajima@intel.com>; Boris Ostrovsky
<boris.ostrovsky@oracle.com>; Joao Marcal Lemos Martins
<joao.m.martins@oracle.com>; Phillip Goerl
<phillip.goerl@oracle.com>
Subject: Re: [edk2-rfc] [edk2-devel] CPU hotplug using
SMM with QEMU+OVMF

On 08/22/19 08:18, Paolo Bonzini wrote:
On 21/08/19 22:17, Kinney, Michael D wrote:
Paolo,

It makes sense to match real HW.
Note that it'd also be fine to match some kind of
official Intel
specification even if no processor (currently?)
supports it.

I agree, because...

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.
that would suggest that matching reset vector code
already exists, and it would "only" need to be
upstreamed to edk2. :)

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?
Yes.
(

This thread (esp. Jiewen's and Mike's messages) are the
first time that I've heard about the *existence* of
such RAM ranges / the chipset feature. :)

Out of interest (independently of virtualization), how
is a general purpose OS informed by the firmware,
"never try to set up DMA to this RAM area"? Is this
communicated through ACPI _CRS perhaps?

... Ah, almost: ACPI 6.2 specifies _DMA, in "6.2.4 _DMA
(Direct Memory Access)". It writes,

For example, if a platform implements a PCI bus
that cannot access
all of physical memory, it has a _DMA object under
that PCI bus that
describes the ranges of physical memory that can be
accessed by
devices on that bus.

Sorry about the digression, and also about being late
to this thread, continually -- I'm primarily following
and learning.

)

Thanks!
Laszlo

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