From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1pKukD-0005kG-F9 for mharc-grub-devel@gnu.org; Thu, 26 Jan 2023 00:24:17 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pKukC-0005k5-AW for grub-devel@gnu.org; Thu, 26 Jan 2023 00:24:16 -0500 Received: from mail-qt1-x82e.google.com ([2607:f8b0:4864:20::82e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pKukA-00085O-2N for grub-devel@gnu.org; Thu, 26 Jan 2023 00:24:16 -0500 Received: by mail-qt1-x82e.google.com with SMTP id x5so557309qti.3 for ; Wed, 25 Jan 2023 21:24:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficientek-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:reply-to:references :in-reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to; bh=cbzYJ8hr4tZCCgkoCWR9kW/oCR7ArPxlKk6CHblGOHc=; b=xlq31PcQmV7+1B5nDEXfhu0MYB/s72df3U0xCduUmMlorrPxxVuI5NovL2EPkW4suF +ikz8mjpKEo0rxzO6I7x44hvq/odTf9ANIkoaOQJdeEtHOO5uEpg6OBHBxNkXXgjm9+P 80OAxgP2m9AgK2fZ7UcdCrakv/+5948B4crIKw+3dLY3P1t0BFPDsisZWI5/w4PKseE+ Czd3yhwrJ0cQWNnW3cSNcnB6sEqP9xImc75Y6ifsetlqsCDevGbx5pbJjFLi5b0PXBBF Mbnxc5Um7ui4/ZcCw3lCo0nAblzQ8en7K28YDSR9XoTqegPVJfJF32HPq2Dva98Gm5ix ZbuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:reply-to:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=cbzYJ8hr4tZCCgkoCWR9kW/oCR7ArPxlKk6CHblGOHc=; b=7BCWwR9II3CVWqVWru4M6iSp57X8eI20g2LIPmjFqTN2JHD1zQlffgNOxiIeVjr+SE 0oqwHEA3MURSe/17BEhPD0K97+9oBRSJtz00eYGG6kjo4J52vx0zUyWvjYgJF+gE2xs5 QiVcoEbl+ZRHaFCC/26q5Wpo3O60Rv7vSzn6JldjTbzk0l1Ua1xXyWe6xoAJPY34O0dY 9es1HLJAXWgnmWckCzfCP24uJDvYdHOm2AyQ6DBZE6XJQMMOPb3zMyYxw1wyxh8o1m+Z I18xRElk5/q0UKD2qx4MVizAG/NwsUQwQ0miXBsvTmFmZS1ARs9wjrP/A9qB2/hbvuBW x42A== X-Gm-Message-State: AO0yUKU41qj8hZ/FOtqi5OelS/DsKf0LryxyWaaxySbpGPHTW056ze8m EB6HRZYaAMu2rEyvM9zccqc8Yg== X-Google-Smtp-Source: AK7set9njolXUSAYa78zOCzNgPT43jLMA4/DU+p9XuaHkv7gwyB+i9m1qTkfbQJ/1d3fu0MWajfPRw== X-Received: by 2002:a05:622a:489:b0:3b8:118c:f0dd with SMTP id p9-20020a05622a048900b003b8118cf0ddmr172899qtx.1.1674710652771; Wed, 25 Jan 2023 21:24:12 -0800 (PST) Received: from crass-HP-ZBook-15-G2 ([37.218.244.251]) by smtp.gmail.com with ESMTPSA id h22-20020ac87456000000b003a82562c90fsm141318qtr.62.2023.01.25.21.24.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Jan 2023 21:24:12 -0800 (PST) Date: Wed, 25 Jan 2023 23:23:56 -0600 From: Glenn Washburn To: Gerd Hoffmann Cc: The development of GNU GRUB , Daniel Kiper Subject: Re: [PATCH] grub-shell: Add flexibility in QEMU firmware handling Message-ID: <20230125232356.518521b4@crass-HP-ZBook-15-G2> In-Reply-To: <20230124081626.a34tvlfivkc6mpoi@sirius.home.kraxel.org> References: <20230121061520.1619840-1-development@efficientek.com> <20230123092809.sycmpu4iu5hn6b6n@sirius.home.kraxel.org> <20230123140947.7998a115@crass-HP-ZBook-15-G2> <20230124081626.a34tvlfivkc6mpoi@sirius.home.kraxel.org> Reply-To: development@efficientek.com X-Mailer: Claws Mail 4.1.0 (GTK 3.24.34; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=2607:f8b0:4864:20::82e; envelope-from=development@efficientek.com; helo=mail-qt1-x82e.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2023 05:24:16 -0000 On Tue, 24 Jan 2023 09:16:26 +0100 Gerd Hoffmann wrote: > Hi, > > > > > Do not load the system 32-bit ARM firmware VARS file because it > > > > must be writable to prevent a data exception and boot failure. > > > > So in order to use the VARS file, it must be copied to a > > > > writable location, but its quite large at 64M and is not needed > > > > to boot successfully. > > > > > > You can load the VARS file with snapshot=on (and drop > > > readonly=on) to make things work without copying the file. > > > > Good to know. Do you know of any benefit to doing this (ie. using > > the installed VARS file)? > > Well, the firmware expects it can write to VARS flash. ovmf has for > historical reasons code to cope with non-flash or readonly VARS (so > -bios works), but armvirt has not. Which is why you see the failures. Well armvirt seems to cope fine if there's no VARS flash provided, it just dies when there is one provided which is readonly. > snapshot=on allows the guest write to a in-RAM throwaway snapshot, > which is the same as using a writable temporary copy of the vars > file, but without the need for a temporary file. Yeah, I get that, but armvirt doesn't even need the VARS file to run. You'll see in this patch that for 32-bit arm, no VARS flash is created when loading the firmware code from the system path or when loading the firmware code from the grub source directory and the VARS file doesn't exist. So what benefit is there to providing the system VARS as a flash device? I can't think of a benefit to using the VARS file if the tests all pass fine without it. I'd prefer to have as few dependencies on files not in the GRUB source as possible. So I like that I don't need to use the system VARS file on 32-bit arm. I wish I could do the same on the other platforms. This patch does no temporary copying of VARS files on any platform and all the QEMU tests run as expected. So using "snapshot=on" won't prevent any copying, which is the main benefit that I see. I do appreciate this suggestion as it might be useful in other work with QEMU, I just don't see how its beneficial here. Glenn