From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39980) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlB9i-0005S7-P6 for qemu-devel@nongnu.org; Thu, 23 Apr 2015 03:02:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YlB9f-0005as-Ju for qemu-devel@nongnu.org; Thu, 23 Apr 2015 03:02:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58217) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlB9f-0005aQ-Bt for qemu-devel@nongnu.org; Thu, 23 Apr 2015 03:02:35 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t3N72X5v004399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 23 Apr 2015 03:02:33 -0400 Message-ID: <1429772550.26641.8.camel@nilsson.home.kraxel.org> From: Gerd Hoffmann Date: Thu, 23 Apr 2015 09:02:30 +0200 In-Reply-To: <553817EC.3080608@redhat.com> 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> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 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: Laszlo Ersek Cc: pbonzini@redhat.com, qemu-devel@nongnu.org, mst@redhat.com 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? 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 ] > 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. cheers, Gerd