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 9793921A134AC for ; Thu, 4 May 2017 07:01:04 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BFC1A7F4A0; Thu, 4 May 2017 14:01:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com BFC1A7F4A0 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=imammedo@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com BFC1A7F4A0 Received: from nial.brq.redhat.com (dhcp-1-118.brq.redhat.com [10.34.1.118]) by smtp.corp.redhat.com (Postfix) with ESMTP id 72ACD1715B; Thu, 4 May 2017 14:00:59 +0000 (UTC) Date: Thu, 4 May 2017 16:00:58 +0200 From: Igor Mammedov To: Laszlo Ersek Cc: Gerd Hoffmann , "Kinney, Michael D" , Paolo Bonzini , edk2-devel-01 , "Yao, Jiewen" , "Fan, Jeff" Message-ID: <20170504160058.2e162b01@nial.brq.redhat.com> 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> <20170504102359.45724558@nial.brq.redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 04 May 2017 14:01:04 +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:01:04 -0000 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 4 May 2017 13:34:13 +0200 Laszlo Ersek wrote: > On 05/04/17 10:23, Igor Mammedov wrote: > > On Thu, 4 May 2017 00:33:27 +0200 > > Laszlo Ersek wrote: > > > > [...] > >> 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. > > Just a thought, > > have you considered firmware setting size it needs explicitly? > > That way we won't have to bump that value on qemu side when > > qemu dictated size becomes too small and won't need compat cruft > > around it. > > The problem is that I don't know what size to set. The per-VCPU SMRAM > demand varies (mostly, grows) over time as edk2's SMM stack gets new > features and/or is refactored occasionally. The size hint would have to > come from OvmfPkg (platform code) while the overwhelming majority of the > SMM stack lives outside of OvmfPkg. > > Also, it's not just data that is allocated from SMRAM, it's also the SMM > driver binaries themselves. The size of those varies even with the > compiler toolchain that you use to build OVMF -- for example, with > gcc-5, link-time optimization is enabled in edk2, which results in > significantly smaller binaries --, and whether you build OVMF for NOOPT > / DEBUG / RELEASE. This kind of difference is likely not significant per > se, but it could be the difference between working with N*100 VCPUs, or > only with N*100-5 VCPUs. looks complicated, but still it would be the best option. Anyways, I don't insist. > So I continue to think of SMRAM size as another board property, like > plain RAM size. If the guest payload doesn't fit, make QEMU provide more > of it, be it disk space, normal RAM, or SMRAM. In fact I think the SMRAM > size property should not be an X-* property but something that users > could *validly* override on the command line, if they wanted to. Even > exposing it on the libvirt level wouldn't be wrong, I believe; the same > way we already expose whether SMM emulation is enabled at all. Agreed, if it's a public property set by management layers and firmware will crash with clear message it would work as well. There is another thing to consider here, when vm is migrated to newer qemu(with newer firmware version) then it might not boot on the next restart due to hitting old set limit. > Thanks > Laszlo