From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.groups.io with SMTP id smtpd.web12.13588.1630305918304640665 for ; Sun, 29 Aug 2021 23:45:18 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=YzakKA/I; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1630305916; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=YSyRQzViC7wXY8Jb9a1jTug/PnUn58wFtTlhRXhjvOI=; b=YzakKA/InzCrSVVwM1p+YvA9S80h3C8COhnr53INai2m1YtBCu0JDhSmE1T/cSVNcjBP4F HE5/owPul4s5CZZitEb9x+9EJknV+VU2imYT+61iZojOmzaNOdeWxNsuuMly1mGqchpmFM Ky4UICJ07SBgp8pFC2iMk9oMVUVXJ0Q= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-549-PQQKq3FQNeWAl0EyrMq1Mw-1; Mon, 30 Aug 2021 02:45:12 -0400 X-MC-Unique: PQQKq3FQNeWAl0EyrMq1Mw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 862931008060; Mon, 30 Aug 2021 06:45:10 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.91]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A8B0B3CC7; Mon, 30 Aug 2021 06:45:09 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 3CC2518007A8; Mon, 30 Aug 2021 08:45:07 +0200 (CEST) Date: Mon, 30 Aug 2021 08:45:07 +0200 From: "Gerd Hoffmann" To: devel@edk2.groups.io, dbautista@newmexicoconsortium.org Cc: ardb+tianocore@kernel.org, jiewen.yao@intel.com, jordan.l.justen@intel.com Subject: Re: [edk2-devel] OVMF: NV Variable Store Layout of Larger Build Targets Message-ID: <20210830064507.ll6jckr4in6lz3f7@sirius.home.kraxel.org> References: <3e91ce2b-15c4-d0d7-4ae8-277d61d0c3c6@newmexicoconsortium.org> MIME-Version: 1.0 In-Reply-To: <3e91ce2b-15c4-d0d7-4ae8-277d61d0c3c6@newmexicoconsortium.org> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, > The current maximum image size of an OVMF image is 4MB, which is > insufficient for storing even a minimal and compressed kernel and initramfs. > To get around this, we've been maintaining our own fork of EDK2 that adds > 8MiB and 16MiB OVMF build targets that have enough room in the DXE volume to > store a reasonably-sized kernel and initramfs. However, it would be > convenient if upstream EDK2 supported these larger OVMF targets. I'm wondering whenever it makes sense to have the 8M option. I think I'd tend to go straight to 16M (which is the max size we can do on x86). > However, as Laszlo mentioned, introducing a larger volume size is > compatibility breaking, and so seizing the opportunity to come up > with a larger non-volatile variable store layout is necessary. > > That said, I would like to use this thread to discuss among hardware > vendors an optimal variable store layout for these larger image sizes. The 2M -> 4M switch happened because the varstore was too small. It was Confirm64KilobytesOfUnauthenticatedVariableStorage test of the the Microsoft Hardware Certification failing. I guess Microsoft has good reasons to test for 64k varstore, probably they expect this is big enough in practice. The varstore size of the 4M layout is *way* above that (see 2M -> 4M commit message): Variable store 56 -> 256 ( +200) Spare area 64 -> 264 ( +200) Assuming 256k varstore is more than enough: Sticking to the 4M variable store layout for the 16M (and maybe 8M) builds looks like the best option to me. I think the varstore would be identical for 4M and 16M builds then, so it should be possible to switch guests from 4M to 16M while keeping the varstore. take care, Gerd