Re: [Qemu-devel] [PATCH v3 for-2.9 0/3] q35: add negotiable broadcast SMI

[Paolo Bonzini]

> > 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