From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44362) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBKTA-00035l-5I for qemu-devel@nongnu.org; Mon, 28 Nov 2016 06:51:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBKT7-0004Mw-0z for qemu-devel@nongnu.org; Mon, 28 Nov 2016 06:51:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:40508) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cBKT6-0004Mi-PK for qemu-devel@nongnu.org; Mon, 28 Nov 2016 06:51:32 -0500 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> <20161128122447.2922aefd@nial.brq.redhat.com> From: Paolo Bonzini Message-ID: Date: Mon, 28 Nov 2016 12:51:25 +0100 MIME-Version: 1.0 In-Reply-To: <20161128122447.2922aefd@nial.brq.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 28/11/2016 12:24, Igor Mammedov wrote: > On Mon, 28 Nov 2016 10:41:42 +0100 > Paolo Bonzini wrote: >=20 >> On 25/11/2016 15:10, Igor Mammedov wrote: >>> On Fri, 25 Nov 2016 03:55:29 -0500 (EST) >>> Paolo Bonzini wrote: =20 >>>>> 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 int= erfaces >>>>> 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). =20 >>>> >>>> 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 har= dware. >>>> I'd rather avoid that. =20 >>> >>> But that's guest side only solution to guest problem, that won't requ= ire >>> any assistance from QEMU/KVM. =20 >> >> 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. >=20 > Does it matter? > If 0x30000 is protected by SMRRs on exiting CPUs so OS can't tamper wit= h it > and SMI is injected on hotplug > (i.e. hotplugged CPU arrives with SMI pin active, we can do this withou= t > inventing PV solution to park/unpark CPU). If you mean placing TSEG at 0x30000 no, that won't work. You need much more memory than that. If you need placing SMRRs there because KVM doesn't need SMRRs to overlap TSEG, there are problems: 0) KVM doesn't implement SMRRs yet anyway. :) 1) while it's true that we don't need SMRRs, on Haswell and newer processors SMRRs also provide the range of physical addresses from which you can execute from in SMM ("SMM Code Access Check"). We do not implement that, but it's planned. 2) I would still not bet on not having other vulnerabilities hidden. For example, can the OS try to have two hotplugs run the initial SMM in parallel? 3) It's really ugly and only works for virt. I wouldn't even call the alternative PV. This thing is not part of the hardware specs; as long as ACPI can describe it, it's not PV, it's firmware. Paolo