From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44216) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zyzk1-0005Wa-SN for qemu-devel@nongnu.org; Wed, 18 Nov 2015 05:13:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zyzjx-0006QQ-Qv for qemu-devel@nongnu.org; Wed, 18 Nov 2015 05:13:29 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50126) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zyzjx-0006Q3-LS for qemu-devel@nongnu.org; Wed, 18 Nov 2015 05:13:25 -0500 References: <1436429849-18052-1-git-send-email-rth@twiddle.net> <564B675B.30207@redhat.com> <564C482A.9040504@twiddle.net> From: Paolo Bonzini Message-ID: <564C4F38.6070607@redhat.com> Date: Wed, 18 Nov 2015 11:13:12 +0100 MIME-Version: 1.0 In-Reply-To: <564C482A.9040504@twiddle.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 00/14] target-i386: Implement MPX extension List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson , qemu-devel@nongnu.org Cc: ehabkost@redhat.com On 18/11/2015 10:43, Richard Henderson wrote: >> 1) pester Intel some more so that they disclose the format of the SMM >> state save area; >=20 > They have done so, and relatively well. Section 34.4.1.1 of the > software developer's manual (I'm looking at 325462-055, June 2015). Relatively well unfortunately is not enough. Unlike AMD, they do not document where the descriptor cache is, which we need to implement SMM save and restore. > The issue, perhaps, is that the Intel and AMD layouts are totally > different. Now, given that we've been using the AMD layout with Intel > emulations maybe that means that it really doesn't matter what layout w= e > use, so long as we're self-consistent. >=20 > Is there anything besides BIOS code that runs in SMM anyway? Do we hav= e > to be compatible with anything besides SeaBIOS in this area? There's OVMF, whose maintainers would really like the SMM state save area to be a superset of the documented format. They have grudgingly accepted that we used AMD's format, which is completely different. But if we used Intel's format and did not put the descriptor cache at the right place, then the next field Intel adds may overlap our descriptor cache fields; we would be back with the same problem. I would just place BNDCFGS at a random offset that is left as reserved in AMD's manual. Since we are at it, we might also find a home for EFER in the 32-bit case, because it is used when LM is 0 but NX is 1. Paolo