Re: CPU hotplug using SMM with QEMU+OVMF
Yao, Jiewen
My comments below.
toggle quoted messageShow quoted text
-----Original Message-----[Jiewen] OK. Let's don’t use the term "global". Do you mean that the CPU being hot-plugged should mask (by default)[Jiewen] I mean all SMIs are blocked for this specific hot-added CPU. And what about other processors? (I'd assume step (01)) is not[Jiewen] No impact to other processors. - Does this part require a new branch somewhere in the OVMF SEC code?[Jiewen] I think this is blocked from hardware perspective, since the first instruction. There are some hardware specific registers can be used to determine if the CPU is new added. I don’t think this must be same as the real hardware. You are free to invent some registers in device model to be used in OVMF hot plug driver. - How do we tell the hot-plugged AP where to start execution? (I.e. that[Jiewen] Same real mode reset vector at FFFF:FFF0. For example, in MpInitLib, we start a specific AP with INIT-SIPI-SIPI,[Jiewen] You can send INIT-SIPI-SIPI to new CPU only after it can access memory. SIPI need give AP an below 1M memory address as waking vector. - What memory is used as stack by the new CPU, when it runs code from[Jiewen] Same as other CPU in normal boot. You can use special reserved memory. QEMU does not emulate CAR (Cache As RAM). The new CPU doesn't have[Jiewen] Excellent point! I don’t think there is problem for real hardware, who always has CAR. Can QEMU provide some CPU specific space, such as MMIO region? - If an attempt is made to hotplug multiple CPUs in quick succession,[Jiewen] The BIOS need consider this as availability requirement. I don’t have strong opinion. You can design a system that required hotplug must be one-by-one, or fail the hot-add. Or you can design a system that did not have such restriction. Again, all we need to do is to maintain the integrity of SMM. The availability should be considered as separate requirement. Again, stack usage could be a concern, even with Cache-As-RAM --[Jiewen] Agree with you on the virtual environment. For real hardware, we do socket level hot-add only. So HT is not the concern. But if you want to do that in virtual environment, a processor specific memory should be considered. Does CPU hotplug apply only at the socket level? If the CPU is[Jiewen] Ditto. [Jiewen] Agree. I do not see the issue.(02) New CPU: (Flash) configure memory control to let it access globalIn QEMU/KVM guests, we don't have to enable memory explicitly, it just [Jiewen] The new CPU does not enable SMI at reset.(03) New CPU: (Flash) send board message to tell host CPU (GPIO->SCI)Maybe we can simplify this in QEMU by broadcasting an SMI to existent At some point of time later, the CPU need enable SMI, right? The "instruction" here means, the host CPUs need tell to CPU to enable SMI. [Jiewen] OS here means the Host CPU running code in OS environment, not in SMM environment.(04) Host CPU: (OS) get message from board that a new CPU is added.I don't understand the OS involvement here. But, again, perhaps QEMU can [Jiewen] Right. That is the register to let host CPU tell new CPU to enable SMI.(06) Host CPU: (SMM) Save 38000, Update 38000 -- fill simple SMMAha, so this is the SMM-only register you mention in step (03). Is the It is platform specific register. Not defined in SDM. You may invent one in device model. [Jiewen] The new CPU exits SMM and return to original place - where it is(08) New CPU: (Flash) Get message - Enable SMI.What code does the new CPU execute after it completes step (10)? Does it interrupted to enter SMM - running code on the flash. [Jiewen] I think you are correct.(11) Host CPU: (SMM) Restore 38000.These steps (i.e., (06) through (11)) don't appear RAS-specific. The Three more comments on the "SMBASE pre-config" approach:[Jiewen] I think you are correct. Also REMOVE_PROCESSOR will be used for hot-remove action. What are some of the other member functions used for? The scary one is[Jiewen] This is to register a new exception handler in SMM. I don’t think this API is involved in hot-add. [Jiewen] Any SMI event. It could be synchronized SMI or asynchronized SMI.===================== (now, the next SMI will bring all CPU into TSEG)OK... but what component injects that SMI, and when? It could from software such as IO write, or hardware such as thermal event. [Jiewen] On real hardware, it is needed because different CPU may have different capability to access different DIMM.(13) New CPU: (Flash) run MRC code, to init its own memory.Why is this needed esp. after step (10)? The new CPU has accessed DRAM I do not think your virtual platform need it. [Jiewen] The OS need use the new CPU at some point of time, right?(14) New CPU: (Flash) Deadloop, and wait for INIT-SIPI-SIPI.I'm confused by these steps. I thought that step (12) would complete the As such, the OS need pull the new CPU into its own environment by INIT-SIPI-SIPI. Thanks!
|
|