From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51515) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cACIC-0006c6-At for qemu-devel@nongnu.org; Fri, 25 Nov 2016 03:55:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cACI9-0005F5-2t for qemu-devel@nongnu.org; Fri, 25 Nov 2016 03:55:36 -0500 Received: from mx4-phx2.redhat.com ([209.132.183.25]:34722) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cACI8-0005De-Ql for qemu-devel@nongnu.org; Fri, 25 Nov 2016 03:55:33 -0500 Date: Fri, 25 Nov 2016 03:55:29 -0500 (EST) From: Paolo Bonzini Message-ID: <885040189.121652.1480064129384.JavaMail.zimbra@redhat.com> In-Reply-To: <20161124190252.286b4045@Igors-MacBook-Pro.local> References: <20161118103659.10448-1-lersek@redhat.com> <20161124155540.1aa7ca37@Igors-MacBook-Pro.local> <1916390024.1734505.1480007155105.JavaMail.zimbra@redhat.com> <20161124190252.286b4045@Igors-MacBook-Pro.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 for-2.9 0/3] q35: add negotiable broadcast SMI List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: Laszlo Ersek , qemu devel list , Kevin O'Connor , "Michael S. Tsirkin" , Gerd Hoffmann , "Jordan Justen (Intel address)" , Michael Kinney > > 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