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 46B4A21A13484 for ; Wed, 3 May 2017 15:33:32 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A4E183D8; Wed, 3 May 2017 22:33:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com A4E183D8 Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com A4E183D8 Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-118.phx2.redhat.com [10.3.116.118]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3EAB2189A8; Wed, 3 May 2017 22:33:28 +0000 (UTC) To: Gerd Hoffmann 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> Cc: "Kinney, Michael D" , "Fan, Jeff" , "Yao, Jiewen" , edk2-devel-01 , Paolo Bonzini From: Laszlo Ersek Message-ID: <64591d6f-b5d9-d73d-26a5-4c157b9bd541@redhat.com> Date: Thu, 4 May 2017 00:33:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1493819062.8581.177.camel@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 03 May 2017 22:33:31 +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: Wed, 03 May 2017 22:33:32 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 05/03/17 15:44, Gerd Hoffmann wrote: > Hi, > >> I propose the following: add a new fw_cfg file which communicates how >> much memory (how many megabytes) the "11b" value in the tseg size >> register will configure. > > I'd prefer to keep fw_cfg out of the picture, and I think we can do it > without too much problems. > > We have a TSEGMB (tseg memory base) register. qemu doesn't implement > it (but I think you can write to it and read back what you've > written). OVMF already uses this register, for the exact purpose you mention. (1) OVMF sets the register in SmmAccessPeiEntryPoint(), which is the entry point of the PEI-phase module that produces PEI_SMM_ACCESS_PPI. (2) OVMF reads the register back in SmramAccessGetCapabilities(), which is built into two modules: - the same PEIM as mentioned above, for producing PEI_SMM_ACCESS_PPI.GetCapabilities(), - a similar-purpose DXE driver, for producing EFI_SMM_ACCESS2_PROTOCOL.GetCapabilities(). Those GetCapabilities() member functions basically return the SMRAM map to the caller. > We could make qemu update that register in case "11b" is written to > the tseg size. The firmware then can read TSEGMB and figure whenever > a large tseg is supported and if so how big it is. Do you mean that QEMU would at once calculate the absolute base of TSEG, downwards from the top of low RAM, expressed in MB? Excerpt from (1): > // > // Set TSEG Memory Base. > // > PciWrite32 (DRAMC_REGISTER_Q35 (MCH_TSEGMB), > (TopOfLowRamMb - FixedPcdGet8 (PcdQ35TsegMbytes)) << MCH_TSEGMB_MB_SHIFT); > > // > // Set TSEG size, and disable TSEG visibility outside of SMM. Note that the > // T_EN bit has inverse meaning; when T_EN is set, then TSEG visibility is > // *restricted* to SMM. > // > EsmramcVal &= ~(UINT32)MCH_ESMRAMC_TSEG_MASK; > EsmramcVal |= FixedPcdGet8 (PcdQ35TsegMbytes) == 8 ? MCH_ESMRAMC_TSEG_8MB : > FixedPcdGet8 (PcdQ35TsegMbytes) == 2 ? MCH_ESMRAMC_TSEG_2MB : > MCH_ESMRAMC_TSEG_1MB; > EsmramcVal |= MCH_ESMRAMC_T_EN; > PciWrite8 (DRAMC_REGISTER_Q35 (MCH_ESMRAMC), EsmramcVal); I guess I could update this to: - set MCH_TSEGMB like now, but also remember the written value - write 11b to MCH_ESMRAMC, and read back MCH_TSEGMB - if the read back value differs from the written one, use that value for tseg size going forward, plus write 11b | T_EN to MCH_ESMRAMC - otherwise, set MCH_ESMRAMC like now. The problem with this is that I need the TSEG size in another module as well, namely PlatformPei. The dispatch order between PlatformPei and SmmAccessPei is unspecified (they have both TRUE for DEPEX). If PlatformPei gets dispatched second, I really wouldn't want to write to MCH_ESMRAMC again, just to query MCH_TSEGMB. (I couldn't just read MCH_TSEGMB because if PlatformPei were dispatched first, then MCH_TSEGMB would still be unset). In other words, I wouldn't like to write a register just to receive the information; I need the information in two places whose relative ordering is unspecified, and one of those already writes the register in question, genuinely. I guess I could hack it around with another dynamic PCD, but that's kind of ugly. If we invented a read-only, side-effect-free PCI config space register that gave me this value plain and simple (similarly to how a new fw_cfg file would do), that would be a lot cleaner for me. I think this would match your earlier alternative where you wrote "Alternatively we could add some qemu-specific register". That's my next preference after fw_cfg. Thanks! Laszlo