From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46425) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlEMH-0004Ti-Bk for qemu-devel@nongnu.org; Thu, 23 Apr 2015 06:27:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YlEMC-000265-0V for qemu-devel@nongnu.org; Thu, 23 Apr 2015 06:27:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39000) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlEMB-00025y-SP for qemu-devel@nongnu.org; Thu, 23 Apr 2015 06:27:43 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 6DC608E3ED for ; Thu, 23 Apr 2015 10:27:43 +0000 (UTC) Message-ID: <5538C91A.2040105@redhat.com> Date: Thu, 23 Apr 2015 12:27:38 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1429521560-2743-1-git-send-email-kraxel@redhat.com> <1429521560-2743-5-git-send-email-kraxel@redhat.com> <55365C33.2090101@redhat.com> <1429628650.21164.24.camel@nilsson.home.kraxel.org> <55381571.4000201@redhat.com> <553817EC.3080608@redhat.com> <1429772550.26641.8.camel@nilsson.home.kraxel.org> In-Reply-To: <1429772550.26641.8.camel@nilsson.home.kraxel.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 5/6] [wip] tseg, part1, not (yet) tested List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann , Laszlo Ersek Cc: qemu-devel@nongnu.org, mst@redhat.com On 23/04/2015 09:02, Gerd Hoffmann wrote: >>> > > The third one is messy. It relies on SMI_EN, which is an ioport a= t >>> > > PMBA+0x30. It requires a configured PMBA. > Isn't that initialized early anyway, because the pm timer lives there? > It's not a regular pci bar exactly to allow early init, so the full pci > bus scan + bar allocation done later will not mess up things. >=20 > [ just a question, could very well be that even when initialized early > it isn't early enough because you need to know the memory layout > before uncompressing the firmware modules ] The nice thing about TSEG is that it's just normal RAM until you lock it. So you can add a HOB very early that reserves that memory, and only later decide whether to use "real" SMM, or just not lock TSEG and jump into the SMM handler. (This would be the "experimentation" setting you were talking about earlier; it would also be used if TSEG is not availabl= e). The fake path would also be used on PIIX. This means you would _always_ use the SMM stack, even if it's not running in SMM, and you could e.g. get rid of the PEI/DXE drivers for flash access. >> > There's another problem with basing this decision in OVMF on >> > SMI_EN.APMC_EN: it is not an idempotent check. At some point the >> > firmware itself has to set SMI_EN.APMC_EN. > Yep, you'll need some variable saying whenever smm is there or not and > check that. Because of this. Or (in case we are going for the fw_cfg > file) because you don't want dig into fw_cfg each time you need to know > this. You can assume that either all of TSEG/SMM/outb(0xb2)/GLB_SMI_EN are available, or none is. Detection can go like this: 1) if APMC_EN =3D 0, SMM is available but other features might not be. Set APMC_EN and GLB_SMI_EN, set SMI_LOCK(*), then clear GLB_SMI_EN. Now APMC_EN is always 1, but a new QEMU won't let you clear GLB_SMI_EN. (*) SMI_LOCK is in the configuration space of device 31 function 0 (byte 0xa0, bit 4) 2) is GLB_SMI_EN =3D 1? Then SMM is available. 3) else, QEMU has set APMC_EN to communicate that SMIs are not available, or SMIs are available (e.g. old QEMU with TCG) but you don't have TSEG. Proceed with fake SMM. Would this work? It is idempotent at least. Even if the OS tries to maliciously set APMC_EN to 0 (SMI_LOCK doesn't lock APMC_EN), the result after step 1 is always going to be the same: APMC_EN=3DGLB_SMI_EN=3D1 on = new QEMU, APMC_EN=3D1/GLB_SMI_EN=3D0 on old QEMU. Paolo