From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56633) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yl2Yg-0007Jg-4i for qemu-devel@nongnu.org; Wed, 22 Apr 2015 17:51:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yl2Ya-0008A9-VN for qemu-devel@nongnu.org; Wed, 22 Apr 2015 17:51:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53351) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yl2Ya-0008A3-Pe for qemu-devel@nongnu.org; Wed, 22 Apr 2015 17:51:44 -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 4B98CB5E8F for ; Wed, 22 Apr 2015 21:51:44 +0000 (UTC) Message-ID: <553817EC.3080608@redhat.com> Date: Wed, 22 Apr 2015 23:51:40 +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> In-Reply-To: <55381571.4000201@redhat.com> 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 another point: On 04/22/15 23:41, Laszlo Ersek wrote: > On 04/21/15 17:04, Gerd Hoffmann wrote: >>> - can the guest somehow use this facility to detect, dynamically, the >>> presence of this feature? (For now I'm thinking about a static build >>> flag for OVMF that would enable SMM support, but I'm 99% sure Jordan >>> will object and ask for a dynamic feature detection.) >> >> Hmm. I think if we merge all the smm / smram / tseg patches in one go >> this should work. Without patches reading the ESMRAMC register returns >> zero. With the patches the three cache-disable bits are hardcoded to >> '1'. This should work for detecting tseg support. >> >> You also have to test for smm support. The current protocol for this is >> that seabios checks whenever smm is already initialized (see >> *_apmc_smm_setup() in seabios/src/fw/smm.c) and if so it skips smm >> initialization. Right now qemu sets the bit on reset when running on >> kvm, so seabios doesn't try to use smm. On tcg the bit is clear after >> reset and seabios actually uses smm mode. > > I started looking into this. Basically the condition for SMM/SMRAM > support is: > > Q35 && SMRAM support && SMM support (1) > > The first subcondition can be checked via the host bridge devid (and > OVMF already does, for other purposes). > > The second one relies on the ESMRAMC, which is in PCI config space. > > The third one is messy. It relies on SMI_EN, which is an ioport at > PMBA+0x30. It requires a configured PMBA. > > The problem for OVMF is the following: this condition is too complex / > too intrusive to evaluate in order to see whether Q35+SMM+SMRAM are > available. > > For that reason, I'd like to ask if it would be possible to introduce a > new fw_cfg file that would simply communicate the end result of the > above expression. 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. This is probably no issue for SeaBIOS, but in OVMF there's a bunch of more-or-less independently dispatched modules that depend on condition (1), and if I set SMI_EN.APMC_EN in some of those modules myself, then code that ends up running later cannot reuse SMI_EN.APMC_EN for determining (1). So I'd have to store the original result in some PCD, but that itself doesn't guarantee ordering either, so it just becomes a huge mess. fw_cfg on the other hand is always available, and this fw_cfg file would never change. Thanks! Laszlo