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.web09.5025.1631178590840611831 for ; Thu, 09 Sep 2021 02:09:51 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=QvW/vBJw; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: philmd@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1631178590; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3TKayYqJSWOYc8n/zhgvQ/qVOHZNvZYZSj8LvBhKqyc=; b=QvW/vBJw23y8KADuT2mlLOJwxfkYQrc7h1NbuS+fCSVlDQzDB3x/G6Qy2N8DD71NmcWnOc gplTmbTU2uQ2eLo4yzgmDbd4qS/EbHq7IKo85aLGTpYzFjSGhEMpFyQgV5/KWSic+D2VgB kUzKknp2UM1zQWk6H4qYqCCtHQGsCHo= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-595-1hRQIm_eNCul_iKXix_gxQ-1; Thu, 09 Sep 2021 05:09:49 -0400 X-MC-Unique: 1hRQIm_eNCul_iKXix_gxQ-1 Received: by mail-wr1-f72.google.com with SMTP id s13-20020a5d69cd000000b00159d49442cbso296571wrw.13 for ; Thu, 09 Sep 2021 02:09:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3TKayYqJSWOYc8n/zhgvQ/qVOHZNvZYZSj8LvBhKqyc=; b=YPg/7nIpc9reXxFV/FEvfWkllisdQt+X7m5a7mmyoPxg9aNC+/1TDZeh00/nu/T7ce shgSgFoxAI2uySxDJe7Q5xeglF0T7U74MTrU2qlHZH4GL65jWkeGoQGbzKJe0HOHqEfb Eq2JyacWOIISsGM6jtpMcT1gKmrJ2nnSbvXKVAIV0XVcdhciAdxHGol70HNabgnHcryg oxyzT8OiD/XjJptY1Ir8Izjfd143MDp/yPsWnyuR9bJxbN1s3LtDXTE/W9ZOEIoGaLRW VB590NIcS2bOjLsrXaG8bC6a33PFebdcsbBDvWsm8ViQzPAn0J7Lp9a8+OU4travpTZj UMfw== X-Gm-Message-State: AOAM531RcBTh5etp3xTq84GmvocHH87oqr3wRX9AEGsbnjc3BmjElulx NamLj+tvvrZrhP9CWPodkyRdovjD+mggqw7WQ4s2nokKPCg6v+YCdMM2/IOaG3IN0zEdLwyAUce xq4mAZOBE6VGQZA== X-Received: by 2002:a1c:f414:: with SMTP id z20mr1898564wma.94.1631178587840; Thu, 09 Sep 2021 02:09:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz39UzYccerEhBxtnCe/aN+Rb/pOvzK0r3DStq4u+o1ThLonX7ISDQYN0/KNDTGTbOIWD+y9g== X-Received: by 2002:a1c:f414:: with SMTP id z20mr1898534wma.94.1631178587548; Thu, 09 Sep 2021 02:09:47 -0700 (PDT) Return-Path: Received: from [192.168.1.36] (21.red-83-52-55.dynamicip.rima-tde.net. [83.52.55.21]) by smtp.gmail.com with ESMTPSA id m6sm1426219wrw.0.2021.09.09.02.09.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Sep 2021 02:09:47 -0700 (PDT) Subject: Re: [edk2-devel] [PATCH v2 1/1] OvmfPkg: Introduce 16MiB flash size for (primarily) Linuxboot To: devel@edk2.groups.io, dbautista@newmexicoconsortium.org, David Edmondson Cc: Ard Biesheuvel , Jiewen Yao , Jordan Justen , Gerd Hoffmann , Leif Lindholm References: <20210903052620.30638-1-dbautista@newmexicoconsortium.org> <20210903052620.30638-2-dbautista@newmexicoconsortium.org> From: =?UTF-8?B?UGhpbGlwcGUgTWF0aGlldS1EYXVkw6k=?= Message-ID: <00c6bca1-a715-0fee-799c-705ef9a9a7bd@redhat.com> Date: Thu, 9 Sep 2021 11:09:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210903052620.30638-2-dbautista@newmexicoconsortium.org> Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=philmd@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 9/3/21 7:26 AM, Devon Bautista wrote: > The largest size flash image currently available for OVMF builds, 4MiB, > is too small to insert a Linux kernel and initramfs into the DXEFV, and > is thus insufficient for testing Linuxboot builds via OVMF. > > Introduce the FD_SIZE_16MB build macro (equivalently, > FD_SIZE_IN_KB=16384), which enlarges the full flash image to 16MiB, the > maximum size available for x86. I understand this is unavoidable to remove the restriction, but this will have a negative impact on clouds memory consumption. ARM clouds are already suffering from having 64MiB flashes, see: https://lore.kernel.org/all/20201116104216.439650-1-david.edmondson@oracle.com/ Some notes to extend the discussion. * Why is QEMU using 2 flashes (CODE & DATA)? My historical understanding is when OVMF was started, QEMU flash model was not supporting sector/bank (write/erase) protection. OVMF requirements were: - CODE section ("secure", not modifiable by the guest) - DATA section (modifiable) The easier way to get the CODE secure is to use different devices, one enforced in "read-only" mode. Being a firmware for virtualized guests, it makes no sense to have the guest upgrade the CODE: it is error-prone, and cheaper to do directly on the host, rebooting the guest. * Why not use a ROM for the CODE section and flash for the DATA one? This is not clear to me. I suppose the firmware wanted to be able to poll the hardware size, and the pflash allow that with CFI I/O requests? * Could we replace the CODE pflash by a ROM device? QEMU provides the -fw_cfg device and versioned machines. To the best of my knowledge it seems doable, with careful modifications in OVMF and ArmVirt. * What are the benefits of using a ROM for the CODE section? - simpler code path, simpler to audit / review, safer - reduce migration burden (no pflash device state) - reduce memory consumption (backing file mmaped with MAP_SHARED) * Is there similar problems with DATA section? The biggest problem is the memory waste, the pflash model was designed to be executable, modifiable, and as fast as possible (for execution). This is achieved by copying the whole flash content in an internal buffer. For DATA flash this is no speed gain but high memory penalty. * Can the DATA section memory consumption be reduced? Yes, various suggestions were posted on QEMU mailing list, but nothing accepted so far, this is still a work in progress, and ideas are welcomed. > Since QEMU commit 0657c65 (hw/i386/pc: > add max combined fw size as machine configuration option), QEMU supports > flash sizes up to 16MiB using the "max-fw-size" property. > > This new 16MiB flash size uses the same non-volatile variable store size > and layout as the default 4MiB flash size to ensure compatibility when > switching to the larger flash size. Since the 4MiB target was created in > commit b24fca0 (OvmfPkg: introduce 4MB flash image (mainly) for Windows > HCK), the variable store size increased by 200KiB to 256KiB, which > should provide an adequate safety margin.