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

[Igor Mammedov]

On Thu, 24 Nov 2016 12:05:55 -0500 (EST)
Paolo Bonzini <address@hidden> wrote:

> 
> > > Okay, this does plug the hole I sketched out above. This logic (the
> > > QEMU-specific unparking) can be done in another platform API in OVMF I
> > > guess (like those in SmmCpuFeaturesLib), but I wonder if we have to
> > > provide the infrastructure in platform code up to the separate SMI
> > > command handler. I think it again depends on those unreleased modules.
> >
> > I don't really like parked CPU idea and related modifications to
> > CPU hotplug MMIO interface.
> > 
> > How about an alternative approach:
> > 
> > 1) on CPU hotplug QEMU generates SMI (if SMIs are enabled)
> >    it doesn't matter if it's a directed (to being hotplugged CPU) or
> >    broadcast SMI)
> >    as hotplugged CPU is in reset state and won't handle SMI until it 
> > receives
> >    SIPI (see SDM: 34.2 SYSTEM MANAGEMENT INTERRUPT: NOTES)
> 
> 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).

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.

> > BTW:
> > I don't see how broadcast SMI could be used reliably at initial boot
> > as all present APs would race toward the same SMBASE when broadcast
> > SIPI is sent so it's either directed SMIs or directed SIPIs, I'm not
> > sure what edk2 actually does.
> 
> It uses directed SMIs via local APIC, to relocate SMBASE one vCPU at a
> time.
> 
> Paolo