From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-il1-f180.google.com (mail-il1-f180.google.com [209.85.166.180]) by mx.groups.io with SMTP id smtpd.web10.595.1634684427390539364 for ; Tue, 19 Oct 2021 16:00:27 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@newmexicoconsortium-org.20210112.gappssmtp.com header.s=20210112 header.b=JMCqFkto; spf=pass (domain: newmexicoconsortium.org, ip: 209.85.166.180, mailfrom: dbautista@newmexicoconsortium.org) Received: by mail-il1-f180.google.com with SMTP id k3so20117640ilu.2 for ; Tue, 19 Oct 2021 16:00:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newmexicoconsortium-org.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=QhPnRkUUo5HED81n4+ousWZ6zF4F3JnxP2tP6VxaaJ0=; b=JMCqFktoGe/9zktRqhQu/7ZfskBdEjAz9vtrSZna6ONpZa+jvVwX3Q+OayGvUKRmsO EU2n2veOKoz1lmzN3XaYGltaqEKcNodxs46u69A8P+ulNOUqh37cMnOpud6adcYHAX/y VJ5LUaO6yH+5a5ur32LxaXW9Y589sdTj4rODZHvJBz55g2If7MnXo+hRi5B/p9PGDoSK BoYS3j4ivpIWhwyEVfr4bKN5WVdrlDoCvKzoq7G5ecF8FkN3aNPvIxx/Zkz1ESEB8Ce2 vhQUTNBVuoJGF5eL5CsAHgQ9tr76J9SS45ZdkAgscA/4sbQoznV8BI0mChqCKGOA1t0E JsfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=QhPnRkUUo5HED81n4+ousWZ6zF4F3JnxP2tP6VxaaJ0=; b=W1lciWseJi62jy1/MGcOR5xHuE8Ryv3tKtX8fCq7FMIGviuVC/ESuqTnx5yr1wWTh1 fTTXnTlSz+gsn6/m6QDLOVGfC1jhsRswD+DEpP7935kU4lqo0oklY/2EFKXE29ijA5KF JLpV4CkhpbCriqSg1nmOBYDIIahuWEnhHsmVFhW80Zpl0qU+WKUKYKGP6tdZ+jr7AaVz MNzCWRr8qsYKhNjLsKq2m9gQ0itgQ8pdkqgNfR1La26Kc/VWLKEcNLRb++Y+N2E3wfYs PFW4PToGN+Ul9KdMDmfd6QUYw/nvE8jJ1iGwiDX4gav6nvzHnoaBgtoMtJ484PSH1HDs wE0Q== X-Gm-Message-State: AOAM533bF4vh5cFNjfJgd+ir6ufAEfAe4Jub494geUjGc/7N+AbwREuC cFVNknj9/rkBsUM38Zd+vj0Rig== X-Google-Smtp-Source: ABdhPJx6T71vZXYTFRnSKV5+VHzb4dF5Y3vP2WBvcG4C4T5v3Dmgs8Mal9h1MzSYYqSZm1O9EMN6GQ== X-Received: by 2002:a05:6e02:190a:: with SMTP id w10mr19987034ilu.243.1634684426500; Tue, 19 Oct 2021 16:00:26 -0700 (PDT) Return-Path: Received: from [10.0.32.77] ([65.155.217.209]) by smtp.gmail.com with ESMTPSA id u14sm208618iob.18.2021.10.19.16.00.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 Oct 2021 16:00:26 -0700 (PDT) Message-ID: Date: Tue, 19 Oct 2021 17:03:30 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [edk2-devel] [PATCH v2 1/1] OvmfPkg: Introduce 16MiB flash size for (primarily) Linuxboot To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , devel@edk2.groups.io, David Edmondson Cc: Ard Biesheuvel , Jiewen Yao , Jordan Justen , Gerd Hoffmann , Leif Lindholm , "Bautista, Devon" References: <20210903052620.30638-1-dbautista@newmexicoconsortium.org> <20210903052620.30638-2-dbautista@newmexicoconsortium.org> <00c6bca1-a715-0fee-799c-705ef9a9a7bd@redhat.com> From: Devon Bautista In-Reply-To: <00c6bca1-a715-0fee-799c-705ef9a9a7bd@redhat.com> Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 9/9/21 03:09, Philippe Mathieu-Daudé wrote: > 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/ Is ARM still padding flash images with zeros up to 64MB? Even so, this patch merely introduces the 16MB macro but does not make it the default. Genuinely, I am wondering how having this optional build macro would conflict with ARM's memory consumption if ARM is already using the default 4MB build target for OVMF, unless ARM is already using a 16MB build target downstream and this would conflict with that. > 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. I'm unsure I have the experience necessary to make an informed comment on these points; I think Gerd and/or the other OVMF maintainers/reviewers would have better insight. Best, Devon