From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49709) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c9xTI-00042n-1V for qemu-devel@nongnu.org; Thu, 24 Nov 2016 12:06:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c9xTE-0002CD-T9 for qemu-devel@nongnu.org; Thu, 24 Nov 2016 12:06:04 -0500 Received: from mx5-phx2.redhat.com ([209.132.183.37]:34621) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c9xTE-0002Bf-KR for qemu-devel@nongnu.org; Thu, 24 Nov 2016 12:06:00 -0500 Date: Thu, 24 Nov 2016 12:05:55 -0500 (EST) From: Paolo Bonzini Message-ID: <1916390024.1734505.1480007155105.JavaMail.zimbra@redhat.com> In-Reply-To: <20161124155540.1aa7ca37@Igors-MacBook-Pro.local> References: <20161118103659.10448-1-lersek@redhat.com> <20161124155540.1aa7ca37@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 > > 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. > 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