From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42083) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBIRb-0008V4-O4 for qemu-devel@nongnu.org; Mon, 28 Nov 2016 04:41:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBIRW-0002Ii-Ii for qemu-devel@nongnu.org; Mon, 28 Nov 2016 04:41:51 -0500 Received: from mail-wj0-x243.google.com ([2a00:1450:400c:c01::243]:35139) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cBIRW-0002IG-BC for qemu-devel@nongnu.org; Mon, 28 Nov 2016 04:41:46 -0500 Received: by mail-wj0-x243.google.com with SMTP id o2so9412840wje.2 for ; Mon, 28 Nov 2016 01:41:45 -0800 (PST) Sender: Paolo Bonzini 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> <20161125151008.139e9f37@nial.brq.redhat.com> From: Paolo Bonzini Message-ID: Date: Mon, 28 Nov 2016 10:41:42 +0100 MIME-Version: 1.0 In-Reply-To: <20161125151008.139e9f37@nial.brq.redhat.com> Content-Type: text/plain; charset=windows-1252 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: "Michael S. Tsirkin" , "Jordan Justen (Intel address)" , qemu devel list , Kevin O'Connor , Gerd Hoffmann , Michael Kinney , Laszlo Ersek On 25/11/2016 15:10, Igor Mammedov wrote: > On Fri, 25 Nov 2016 03:55:29 -0500 (EST) > Paolo Bonzini wrote: >>> 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. No, I don't think it can be guest-only. The initial value of SMRRs is undefined, and SMRRs are per processor. The newly-hotplugged CPU has no SMRRs defined when it is started up. > 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? The firmware tells the BMC to do it. I don't know what the firmware-BMC interface looks like. >>> 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)) Yes, of course---that's why I'm bringing up in the context of this series. Paolo