From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.54]) by mx.groups.io with SMTP id smtpd.web09.6171.1629508206625673876 for ; Fri, 20 Aug 2021 18:10:08 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@newmexicoconsortium-org.20150623.gappssmtp.com header.s=20150623 header.b=F8Nq7TTY; spf=none, err=SPF record not found (domain: newmexicoconsortium.org, ip: 209.85.216.54, mailfrom: dbautista@newmexicoconsortium.org) Received: by mail-pj1-f54.google.com with SMTP id qe12-20020a17090b4f8c00b00179321cbae7so8465621pjb.2 for ; Fri, 20 Aug 2021 18:10:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newmexicoconsortium-org.20150623.gappssmtp.com; s=20150623; h=to:from:subject:cc:message-id:date:user-agent:mime-version :content-language; bh=GOP1EE+uYAEQRO2ozwd6pFYfWgxPVJ/ktLKVDkhEXOI=; b=F8Nq7TTYCQjWhZn+pT9rhilVWO0GEXOyLB+b040dFK9N3fmWUCBNxnU431LgP2OLlb 7GwPhrIPfwnHf2spdEqNlQaGqiRZe/2RkEryAkwo9GfXEqnadHV8cVP+npEiN6gCaf5g +hcSY7MdKyCmU9iqDEMXRQs+RIwE9tKKquY/BPT52CXZzL/QQIPXz0p4KDMf8+NjzGjz cZnpKgcZgqHkg0qY8Cvmxc7EdZTKQWnw+LitiZFJFoQx3dq6aM3nl1Ndeq53HsijiksC UIhbrcogHs/9wZC9bCAWM2ZUpS71s6uv7MncpPTGRZn4joaxSlUEdf5Y33oGlLpTwE+F D2+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:cc:message-id:date:user-agent :mime-version:content-language; bh=GOP1EE+uYAEQRO2ozwd6pFYfWgxPVJ/ktLKVDkhEXOI=; b=TJDPWLZW7YoDdKwA3KS0Gptqm9rzNvphPEgDwjPYX/es4D7K0emBSIQUzUAPGjBuML dOOQtjppkkV0X6tgxRSrPhRoblcxhl2ijmk6YhYY+jFfs6It+bc5kvBxxZTD73vE7B7d Foz8wAJBqYOpkeWtb8UGL/Gg3h8Q0JjxNdkviBvxyMWNj6jN67KJNqzMrpodekSykkVR J8Kuzfq2Sat1vNQ5SEUuiIMXDF6hCDdI50tWgtqejThbDU6S+bOrvhKrE018d7Sevz6Q SKuh+XDP4f9RCYy9vI1SCNSFR/m1WfJGHOUfAZ+nYu3VJQELfY+WoER7FD0X8DA0JzKa nIVg== X-Gm-Message-State: AOAM530UZqpdxrKsjHSZdwvG0BSi5F0uBo0ghoJLH0R6NXltHIUmNQtO jl7KxZK4gsBKYSit/YmqbLrVmw== X-Google-Smtp-Source: ABdhPJzr00xhsA5fmPugsZW1bO2j/QjgDwRYKwVo5nKqPYE65hb+r33IJx2WbVDwbRDd3FDdm8wPcw== X-Received: by 2002:a17:90b:1102:: with SMTP id gi2mr7394535pjb.43.1629508204577; Fri, 20 Aug 2021 18:10:04 -0700 (PDT) Return-Path: Received: from devons-mbp-wireless.local (c-73-48-255-158.hsd1.ca.comcast.net. [73.48.255.158]) by smtp.gmail.com with ESMTPSA id 6sm12606557pjk.1.2021.08.20.18.10.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 Aug 2021 18:10:04 -0700 (PDT) To: devel@edk2.groups.io From: "Devon Bautista" Subject: OVMF: NV Variable Store Layout of Larger Build Targets Cc: ardb+tianocore@kernel.org, jiewen.yao@intel.com, jordan.l.justen@intel.com Message-ID: <3e91ce2b-15c4-d0d7-4ae8-277d61d0c3c6@newmexicoconsortium.org> Date: Fri, 20 Aug 2021 18:10:02 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------28F7D51AF4B3CD8ADD186C27" Content-Language: en-US --------------28F7D51AF4B3CD8ADD186C27 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello All, I am currently working with the Linuxboot developers to improve testing kernel + initramfs pairs in firmware using OVMF. 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. In discussing this with the previous OVMF maintainer Laszlo Ersek here , it was brought up that: * The trend of the ever-growing DXE-phase warrants a larger firmware volume size * 8MiB and 16MiB image sizes seem to be justified because of this QEMU commit 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. Best, Devon --------------28F7D51AF4B3CD8ADD186C27 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hello All,

I am currently working with the Linuxboot developers to improve testing kernel + initramfs pairs in firmware using OVMF.

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.

In discussing this with the previous OVMF maintainer Laszlo Ersek here, it was brought up that:

  • The trend of the ever-growing DXE-phase warrants a larger firmware volume size
  • 8MiB and 16MiB image sizes seem to be justified because of this QEMU commit

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.

Best,
Devon

--------------28F7D51AF4B3CD8ADD186C27--