From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48304) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlBlX-0000Xg-QM for qemu-devel@nongnu.org; Thu, 23 Apr 2015 03:41:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YlBlS-00011t-R9 for qemu-devel@nongnu.org; Thu, 23 Apr 2015 03:41:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37495) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlBlS-00011o-IS for qemu-devel@nongnu.org; Thu, 23 Apr 2015 03:41:38 -0400 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t3N7fbWZ023903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 23 Apr 2015 03:41:38 -0400 Message-ID: <5538A22D.7020302@redhat.com> Date: Thu, 23 Apr 2015 09:41:33 +0200 From: Laszlo Ersek 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: 7bit 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 Cc: pbonzini@redhat.com, qemu-devel@nongnu.org, mst@redhat.com On 04/23/15 09:02, Gerd Hoffmann wrote: > Hi, > >>> The third one is messy. It relies on SMI_EN, which is an ioport at >>> PMBA+0x30. It requires a configured PMBA. > > Isn't that initialized early anyway, because the pm timer lives there? TimerLib (which is based in OVMF's case on the PM timer) is not needed / used before PEI in the default case. It is used in SEC only when -D SOURCE_DEBUG_ENABLE is passed for the build (which is "never" in practice). > 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. > > [ 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 ] I'm trying to avoid that; the decompression happens to a low fixed range. >> 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. The annoying limitation with SEC is that it cannot use normal C static variables, nor PCDs. It is okay if SEC is a bit wasteful on fw_cfg (and even in SEC I might be able to cache the result in a local variable and pass it around). In PEI I can already use static variables (because OVMF is unorthodox and runs PEI modules from RAM, not flash), plus I can set PCDs (because in PEI the PCDs live in a dedicated HOB, and that HOB is allocated from RAM (independently of OVMF)). I'll ask Jordan too about the dynamic feature detection, because there's another big hurdle with it (selecting a LockBox library instance at runtime, dependent on the presence of SMM). Deciding about SMM support at build time would make things hugely easier (because that's how firmware for physical platforms is built as well). Thanks Laszlo