> > Parked CPUs are exactly how it works on real hardware (the arbitrator is > > the > > BMC, while we have QEMU in its place). The problem is that, if you just > > place the hotplugged CPU in reset state, there is a race between the OSPM > > and the firmware. The OSPM can place its own code at 0x30000 and send > > INIT/SIPI/SMI before the firmware gets round to doing it. > > if 0x30000 were covered by SMRR range, then OSPM wouldn't able to > place its own code there and there wouldn't be any need in side interfaces > to put and get CPU in/from some undefined by spec state (parked). > > But above would imply a large block allocated at 0x30000 to fit all > possible CPUs+1, not sure if it's doable (maybe edk2 wouldn't have > big issues with reserving large block in lowmem).
If you mean that the default SMRR range would include 0x30000 for an hotplugged CPU, that would work but it is a significant departure from real hardware. I'd rather avoid that. > Suggestion to use CPU hotplug MMIO interface to unpark CPU also doesn't > seem to be secure as it's not protected from OSPM, hence OPSM could > unpark CPU and hijack SMBASE all the same. > It looks like we need only SMM accessible guest/host interface to make > CPU unparking secure or cover default SMBASE by SMRR. Yes, unparking would be accessible only from SMM if the unparking feature is negotiated. Paolo
