From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 3F51B21A13487 for ; Thu, 4 May 2017 07:52:06 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9A73D3DBD3; Thu, 4 May 2017 14:52:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9A73D3DBD3 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=kraxel@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 9A73D3DBD3 Received: from nilsson.home.kraxel.org (ovpn-116-101.ams2.redhat.com [10.36.116.101]) by smtp.corp.redhat.com (Postfix) with ESMTP id E59615DD67; Thu, 4 May 2017 14:52:04 +0000 (UTC) Received: by nilsson.home.kraxel.org (Postfix, from userid 500) id F173B80A03; Thu, 4 May 2017 16:52:02 +0200 (CEST) Message-ID: <1493909522.371.42.camel@redhat.com> From: Gerd Hoffmann To: Laszlo Ersek Cc: "Kinney, Michael D" , "Fan, Jeff" , "Yao, Jiewen" , edk2-devel-01 , Paolo Bonzini Date: Thu, 04 May 2017 16:52:02 +0200 In-Reply-To: References: <1382eb04-9646-133b-9ce5-8293cb54745f@redhat.com> <1493794647.8581.144.camel@redhat.com> <159c4eae-4e13-7958-59f4-dfab4c1bf16e@redhat.com> <1493819062.8581.177.camel@redhat.com> <64591d6f-b5d9-d73d-26a5-4c157b9bd541@redhat.com> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 04 May 2017 14:52:05 +0000 (UTC) Subject: Re: SMRAM sizes on large hosts X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 14:52:06 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, > If we invent such a new register, it should be in a location that is > either read-only, or zeroed-on-reset, in current QEMU. Otherwise, new > firmware running on old QEMU could be misled by a guest OS that writes > to this register, and then either reboots or enters S3. Good point, we need to be quite careful here to not open security holes. Current state is that pretty much all pci config space is writable and not cleared on reset. So no easy way out. > ... With this in mind, I don't oppose "having to write somewhere to read > back the result", but then let's please make that write access as well > to the same new qemu-specific register, and not to MCH_ESMRAMC. That should work, yes. Write '1' to the register, then read back. If it is still '1' -> no big tseg support. Otherwise it returns the tseg size in some form, and "11b" in ESMRAMC can be used to pick that. cheers, Gerd