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 236CE21A07080 for ; Wed, 3 May 2017 06:14:28 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 853A180F8D; Wed, 3 May 2017 13:14:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 853A180F8D Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 853A180F8D 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 628CC17F2C; Wed, 3 May 2017 13:14:24 +0000 (UTC) To: Paolo Bonzini , Gerd Hoffmann , "Kinney, Michael D" References: <1382eb04-9646-133b-9ce5-8293cb54745f@redhat.com> <1493794647.8581.144.camel@redhat.com> <49e28e04-2a61-c3d8-790a-3c08cf664a07@redhat.com> Cc: "Fan, Jeff" , "Yao, Jiewen" , edk2-devel-01 From: Laszlo Ersek Message-ID: <071089ea-c73b-3851-899f-829bfe532867@redhat.com> Date: Wed, 3 May 2017 15:14:23 +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: <49e28e04-2a61-c3d8-790a-3c08cf664a07@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 03 May 2017 13:14:27 +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 13:14:28 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 05/03/17 14:56, Paolo Bonzini wrote: > > > On 03/05/2017 08:57, Gerd Hoffmann wrote: >> qemu implements what physical q35 support. The extended smram register >> has two bits for the tseg size, three out of the four values are used >> (for 1, 2, 8 MB sizes). "11" is reserved in the specs. We could use >> "11" to implement a bigger tseg. Current code sets the tseg size to >> zero for "11". Alternatively we could add some qemu-specific register. > > If you can set TSEG while SMRAM is closed, you could detect that in > edk2. According to Laszlo 32 MB should be more than enough, and we > could enable it only for >192 CPUs. (Seeing this just now.) I'd prefer a solution that would keep the fw logic / code flow related to register configuration intact, and would just replace a few numbers / constants if possible. And, whether the "largest TSEG size" (number of MBs) that QEMU exposed in the new fw_cfg file depended *only* on the machine type, or on other config elements as well (such as max VCPU count), that would be QEMU's prerogative of course. To me personally, the ability (via fw_cfg) to ask / request the following looks best: - Is there a dynamic largest? (= does the fw_cfg file exist?) - What is it exactly? (= what are its contents?) - Please give me it. (= write 11b) Thanks, Laszlo >> When implementing this in qemu we will have to do it runtime-switchable, >> for backward compatibility with older qemu versions. So ideally >> firmware would detect somehow whenever qemu supports a bigger tseg or >> not and adapt at runtime. If edk2 can't do this we would need two edk2 >> builds ...