[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v3 for-2.9 0/3] q35: add negotiable broadcast SMI
Date: Fri, 25 Nov 2016 03:55:29 -0500 (EST)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]