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.
