-----Original Message-----
From: Paolo Bonzini [mailto:pbonzini@...]
Sent: Thursday, August 22, 2019 3:18 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 22/08/19 22:06, Kinney, Michael D wrote:

The SMBASE register is internal and cannot be directly

accessed by any

CPU. There is an SMBASE field that is member of the

SMM Save State

area and can only be modified from SMM and requires the

execution of

an RSM instruction from SMM for the SMBASE register to

be updated from

the current SMBASE field value. The new SMBASE

register value is only

used on the next SMI.

Actually there is also an SMBASE MSR, even though in
current silicon it's read-only and its use is
theoretically limited to SMM-transfer monitors. If that
MSR could be made accessible somehow outside SMM, that
would be great.

Once all the CPUs have been initialized for SMM, the

CPUs that are not

needed can be hot removed. As noted above, the SMBASE

value does not

change on an INIT. So as long as the hot add operation

does not do a

RESET, the SMBASE value must be preserved.

IIRC, hot-remove + hot-add will unplugs/plugs a
completely different CPU.

Another idea is to emulate this behavior. If the hot

plug controller

provide registers (only accessible from SMM) to assign

the SMBASE

address for every CPU. When a CPU is hot added, QEMU

can set the

internal SMBASE register value from the hot plug

controller register

value. If the SMM Monarch sends an INIT or an SMI from

the Local APIC

to the hot added CPU, then the SMBASE register should

not be modified

and the CPU starts execution within TSEG the first time

it receives an SMI.

Yes, this would work. But again---if the issue is real
on current hardware too, I'd rather have a matching
solution for virtual platforms.

If the current hardware for example remembers INIT-
preserved across hot-remove/hot-add, we could emulate
that.

I guess the fundamental question is: how do bare metal
platforms avoid this issue, or plan to avoid this issue?
Once we know that, we can use that information to find a
way to implement it in KVM. Only if it is impossible
we'll have a different strategy that is specific to our
platform.

Paolo

Jiewen and I can collect specific questions on this

topic and continue

the discussion here. For example, I do not think there

is any method

other than what I referenced above to program the

SMBASE register, but

I can ask if there are any other methods.