From: Ani Sinha <ani@anisinha.ca>
To: Igor Mammedov <imammedo@redhat.com>
Cc: Eduardo Habkost <eduardo@habkost.net>,
"Michael S. Tsirkin" <mst@redhat.com>,
Richard Henderson <richard.henderson@linaro.org>,
qemu-devel@nongnu.org, kraxel@redhat.com,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH] hw/i386/pc: when adding reserved E820 entries do not allocate dynamic entries
Date: Thu, 24 Feb 2022 18:14:35 +0530 [thread overview]
Message-ID: <CAARzgwyTsbpxHAko9iLE1RSeuJCAEvRywdQ25e93oLkvSWP8GA@mail.gmail.com> (raw)
In-Reply-To: <20220224100345.2bdfc9d9@redhat.com>
On Thu, Feb 24, 2022 at 2:33 PM Igor Mammedov <imammedo@redhat.com> wrote:
>
> On Wed, 23 Feb 2022 17:30:34 +0530
> Ani Sinha <ani@anisinha.ca> wrote:
>
> > On Wed, Feb 23, 2022 at 2:34 PM Igor Mammedov <imammedo@redhat.com> wrote:
> > >
> > > On Thu, 10 Feb 2022 18:58:21 +0530
> > > Ani Sinha <ani@anisinha.ca> wrote:
> > >
> > > > When adding E820_RESERVED entries we also accidentally allocate dynamic
> > > > entries. This is incorrect. We should simply return early with the count of
> > > > the number of reserved entries added.
> > >
> > > can you expand commit message to explain what's wrong and
> > > how problem manifests ... etc.
> >
> > The issue has been present for the last 8 years without apparent
> > visible issues. I think the only issue is that the bug allocates more
> > memory in the firmware than is actually needed.
>
> let me repeat: Why do you think it's an issue or why it's wrong
Allocating more memory than what we need unnecessarily bloats up the
rom. We should not be allocating memory that we do not use.
>
> >
> > >
> > > >
> > > > fixes: 7d67110f2d9a6("pc: add etc/e820 fw_cfg file")
> > > > cc: kraxel@redhat.com
> > > > Signed-off-by: Ani Sinha <ani@anisinha.ca>
> > > > ---
> > > > hw/i386/e820_memory_layout.c | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/hw/i386/e820_memory_layout.c b/hw/i386/e820_memory_layout.c
> > > > index bcf9eaf837..afb08253a4 100644
> > > > --- a/hw/i386/e820_memory_layout.c
> > > > +++ b/hw/i386/e820_memory_layout.c
> > > > @@ -31,6 +31,8 @@ int e820_add_entry(uint64_t address, uint64_t length, uint32_t type)
> > > > entry->type = cpu_to_le32(type);
> > > >
> > > > e820_reserve.count = cpu_to_le32(index);
> > > > +
> > > > + return index;
> > > > }
> > >
> > > this changes e820_table size/content, which is added by fw_cfg_add_file() to fwcfg,
> > > as result it breaks ABI in case of migration.
> >
> > Ugh. So should we keep the bug? or do we add config setting to handle
> > the ABI breakage.
> >
>
next prev parent reply other threads:[~2022-02-24 12:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-10 13:28 [PATCH] hw/i386/pc: when adding reserved E820 entries do not allocate dynamic entries Ani Sinha
2022-02-10 16:10 ` Philippe Mathieu-Daudé via
2022-02-11 11:19 ` Ani Sinha
2022-02-23 9:04 ` Igor Mammedov
2022-02-23 12:00 ` Ani Sinha
2022-02-24 9:03 ` Igor Mammedov
2022-02-24 12:44 ` Ani Sinha [this message]
2022-02-24 13:21 ` Igor Mammedov
2022-02-28 10:28 ` Ani Sinha
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAARzgwyTsbpxHAko9iLE1RSeuJCAEvRywdQ25e93oLkvSWP8GA@mail.gmail.com \
--to=ani@anisinha.ca \
--cc=eduardo@habkost.net \
--cc=imammedo@redhat.com \
--cc=kraxel@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).