"Laszlo Ersek" <lersek@...> wrote: yep, you can use it to iterate over hotplugged CPUs. hw side (QEMU) uses cpu_hotplug_ops as IO write/read handlers and firmware side (ACPI) scannig for hotplu

"Laszlo Ersek" <lersek@...> wrote: we can try to resurrect and put over it some kind of protocol to describe which CPUs to where hotplugged. or we could put a parameter into SMI status register

"Laszlo Ersek" <lersek@...> wrote: Laszlo, thanks for trying it out. It's nice to hear that approach is somewhat usable. Hopefully we won't have to invent 'paused' cpu mode. Pls CC me on your p

"Laszlo Ersek" <lersek@...> wrote: [...] If I recall correctly, CPU consumes 64K of save/restore area. The rest 64K are temporary RAM for using in SMI relocation handler, if it's possible to ge

"Laszlo Ersek" <lersek@...> wrote: If we don't have to 'park' hotplugged CPUs, then I don't see a need for an extra controller. Thanks for the tip! ... patches with a stolen register are on the

test lockable SMRAM at default SMBASE feature introduced by commit "q35: implement 128K SMRAM at default SMBASE address" Signed-off-by: Igor Mammedov <imammedo@...> --- tests/q35-test.c | 105 +

Use commit (2f295167e0 q35/mch: implement extended TSEG sizes) for inspiration and (ab)use reserved register in config space at 0x9c offset [*] to extend q35 pci-host with ability to use 128K at 0x300

Try #2 using PCI config space of MCH to negotiate/lock SMRAM at 0x30000. CC: yingwen.chen@... CC: devel@edk2.groups.io CC: phillip.goerl@... CC: alex.williamson@... CC: jiewen.yao@

Laszlo Ersek <lersek@...> wrote: It looks like fwcfg smi feature negotiation isn't reusable in this case. I'd prefer not to add another device just for another SMI feature negotiation/activatio

lpc already has SMI negotiation feature, extend it by adding optin ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT to supported features. Writing this bit into "etc/smi/requested-features" fw_cfg file, tells QEMU to

Laszlo Ersek <lersek@...> wrote: I guess we at point where patch is better then words, I'll send one as reply here shortly. I've just implemented subset of above (opened, closed+locked). I didn

Laszlo Ersek <lersek@...> wrote: yep, I'm looking at it from theoretical perspective so far, but what could be done in reality might be limited. it could be stolen RAM + black hole like TSEG, a