From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <pbonzini@redhat.com>
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 2DC3F21A134BB
 for <edk2-devel@ml01.01.org>; Wed,  3 May 2017 05:57:09 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
 (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by mx1.redhat.com (Postfix) with ESMTPS id 41C293B71F;
 Wed,  3 May 2017 12:57:08 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 41C293B71F
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=pbonzini@redhat.com
DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 41C293B71F
Received: from [10.36.118.18] (ovpn-118-18.ams2.redhat.com [10.36.118.18] (may
 be forged))
 by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id
 v43CuvvI018314
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
 Wed, 3 May 2017 08:57:02 -0400
To: Gerd Hoffmann <kraxel@redhat.com>,
 "Kinney, Michael D" <michael.d.kinney@intel.com>
References: <1382eb04-9646-133b-9ce5-8293cb54745f@redhat.com>
 <E92EE9817A31E24EB0585FDF735412F57D1700F8@ORSMSX113.amr.corp.intel.com>
 <1493794647.8581.144.camel@redhat.com>
Cc: Laszlo Ersek <lersek@redhat.com>, "Fan, Jeff" <jeff.fan@intel.com>,
 "Yao, Jiewen" <jiewen.yao@intel.com>,
 edk2-devel-01 <edk2-devel@ml01.01.org>
From: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <49e28e04-2a61-c3d8-790a-3c08cf664a07@redhat.com>
Date: Wed, 3 May 2017 14:56:57 +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: <1493794647.8581.144.camel@redhat.com>
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16
 (mx1.redhat.com [10.5.110.30]); Wed, 03 May 2017 12:57:08 +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  <edk2-devel.lists.01.org>
List-Unsubscribe: <https://lists.01.org/mailman/options/edk2-devel>,
 <mailto:edk2-devel-request@lists.01.org?subject=unsubscribe>
List-Archive: <http://lists.01.org/pipermail/edk2-devel/>
List-Post: <mailto:edk2-devel@lists.01.org>
List-Help: <mailto:edk2-devel-request@lists.01.org?subject=help>
List-Subscribe: <https://lists.01.org/mailman/listinfo/edk2-devel>,
 <mailto:edk2-devel-request@lists.01.org?subject=subscribe>
X-List-Received-Date: Wed, 03 May 2017 12:57:09 -0000
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit



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.

Paolo

> 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 ...