From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40222) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cAHCl-0007sP-EL for qemu-devel@nongnu.org; Fri, 25 Nov 2016 09:10:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cAHCf-00076g-P5 for qemu-devel@nongnu.org; Fri, 25 Nov 2016 09:10:19 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53966) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cAHCf-00075i-Iz for qemu-devel@nongnu.org; Fri, 25 Nov 2016 09:10:13 -0500 Date: Fri, 25 Nov 2016 15:10:08 +0100 From: Igor Mammedov Message-ID: <20161125151008.139e9f37@nial.brq.redhat.com> In-Reply-To: <885040189.121652.1480064129384.JavaMail.zimbra@redhat.com> 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> <885040189.121652.1480064129384.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: Paolo Bonzini Cc: "Michael S. Tsirkin" , "Jordan Justen (Intel address)" , qemu devel list , Kevin O'Connor , Gerd Hoffmann , Michael Kinney , Laszlo Ersek On Fri, 25 Nov 2016 03:55:29 -0500 (EST) Paolo Bonzini wrote: > > > 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. But that's guest side only solution to guest problem, that won't require any assistance from QEMU/KVM. Baremetal would also benefit from it as it won't need to implement unpark logic anymore. it should also work for existing HW that has unpark logic. Do you have any pointers to how hardware does unparking now? > > 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. I suppose we could check in MMIO handler that all CPUs are in SMM mode before allowing unparking or ignore command if they are not. For compat reasons unpark should be optin feature (i.e. firmware should explicitly enable it to avoid breaking existing configurations (SeaBIOS)) > > Paolo >