From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 849C7C433DB for ; Tue, 16 Feb 2021 15:24:22 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CDBC261606 for ; Tue, 16 Feb 2021 15:24:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CDBC261606 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=dme.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:43734 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lC2D6-0008G3-NI for qemu-devel@archiver.kernel.org; Tue, 16 Feb 2021 10:24:20 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:45754) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lC2B0-0006yj-JP for qemu-devel@nongnu.org; Tue, 16 Feb 2021 10:22:15 -0500 Received: from mail-wr1-x42d.google.com ([2a00:1450:4864:20::42d]:34808) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lC2Ax-0008JP-SS for qemu-devel@nongnu.org; Tue, 16 Feb 2021 10:22:10 -0500 Received: by mail-wr1-x42d.google.com with SMTP id n4so10564635wrx.1 for ; Tue, 16 Feb 2021 07:22:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dme-org.20150623.gappssmtp.com; s=20150623; h=to:cc:subject:in-reply-to:references:from:date:message-id :mime-version:content-transfer-encoding; bh=YBsxjlXjlQAODSDZ0pXAR17GD22Gx+AANhmStiVFbaA=; b=K+CnLB7Eqj15BheuS4XfTJDcZMLUtF/x1QTDug2aCpOI2L16Kp+Pdr8IwKj6pBXNKd tV3nz7Gms823fm9ii1x4eB73oFDWx6PV/d+UPstVZwTF2ccs65tJrWsSyWzJZ+tLiHgi KLE4dvU9tydoTxEXOp3wAYdexiM/bGuaL2lTmYR4eeodpyBqLW61B/VHKnRaz/4nuchZ 5MokCmxn5XOSx5xm7gjOk2TSSq1y6BywUjlkvoVO+cTckEIINPTjPrpVA6f+Idl5P2I6 yl1v+sIjUICNGcmQEZXgCX+ywxCt+cw6O7zTB+DrI7lgpUZ52XIq0Pw0RzM3xmqfZmE7 KG3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:subject:in-reply-to:references:from:date :message-id:mime-version:content-transfer-encoding; bh=YBsxjlXjlQAODSDZ0pXAR17GD22Gx+AANhmStiVFbaA=; b=OEfMvIdb4yFYuXPnUsgyiRAL3VOPMuth/NZ1CrhhXxFW3VPZYqhavwXw2Ux/FSpmP4 CajJmdTWo6gMTcT6eZbXAv2paxz94fufw99t+sehLtLEJriN1Wnfg686o5dpNGvTL1D9 Dhv9zbTtFf8BFFjweF59zXRmfWuwdNEhy09z+G9dLKQxuVwvvecg8tX3whghxdsdhWUj CGywuwdi2mIOn00GZEHmUA3q0LkNj94DP5QdYg+K94Dwf1ks4VtfC1YF+GCuZMzcFFqd oMezvHNrsA7UXZf5eFnOwu02LYgM+vePECxuygmV/2HOnIL74sEOD3Sk2qU1RpeM3ZAq RD1g== X-Gm-Message-State: AOAM533aadWptUYi83a2EkQsILhh1sXeK7Iy0otL3ILstdETAnC+ZLaV hlUaCWq+bqQcOlXj2XHCnSwN7w== X-Google-Smtp-Source: ABdhPJxE0mSZVe6RPXoltk+sf5l8dosueDnzVZQaGGX8D2FBpJi2QMxBOujechlEUPhXOEUksLuHNQ== X-Received: by 2002:adf:f591:: with SMTP id f17mr24367402wro.60.1613488925437; Tue, 16 Feb 2021 07:22:05 -0800 (PST) Received: from disaster-area.hh.sledj.net (disaster-area.hh.sledj.net. [2001:8b0:bb71:7140:64::1]) by smtp.gmail.com with ESMTPSA id o129sm4190138wme.21.2021.02.16.07.22.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Feb 2021 07:22:05 -0800 (PST) Received: from localhost (disaster-area.hh.sledj.net [local]) by disaster-area.hh.sledj.net (OpenSMTPD) with ESMTPA id 817d484e; Tue, 16 Feb 2021 15:22:04 +0000 (UTC) To: Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , qemu-block@nongnu.org Subject: Re: [RFC PATCH 0/3] hw/pflash_cfi01: Reduce memory consumption when flash image is smaller than region In-Reply-To: References: <20210216142721.1985543-1-david.edmondson@oracle.com> X-HGTTG: zarquon From: David Edmondson Date: Tue, 16 Feb 2021 15:22:04 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: neutral client-ip=2a00:1450:4864:20::42d; envelope-from=dme@dme.org; helo=mail-wr1-x42d.google.com X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 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_NEUTRAL=0.779, UNPARSEABLE_RELAY=0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kevin Wolf , qemu-devel@nongnu.org, Max Reitz Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Tuesday, 2021-02-16 at 16:03:05 +01, Philippe Mathieu-Daud=C3=A9 wrote: > I am not a block expert, but I wonder if something like this could > be used: > > - create a raw (parent) block image of 64MiB > > - add a raw (child) block with your 768kB of VARS file > > - add a null-co (child) block of 63Mib + 256kiB > > - pass the parent block to the pflash device I'm not clear how this would behave if there is a write to the device at (say) 1MiB. More philosophically, how should it behave? My expectation was that if the machine says that there is 64MiB of writable flash, we have to allow writes throughout the full 64MiB and (significantly) persist them to the backing block device. Just because the backing block device started out 768KiB big doesn't mean that we should not write to the remaining extent if that's what the VM attempts. Would the above approach achieve that? (It doesn't sound like it.) dme. --=20 No visible means of support and you have not seen nothing yet.