From: Gerd Hoffman <kraxel@redhat.com>
To: "Gupta, Pankaj" <pankaj.gupta@amd.com>
Cc: "Dionna Glaze" <dionnaglaze@google.com>,
qemu-devel@nongnu.org, Xu@google.com,
"Min M" <min.m.xu@intel.com>, "Xiaoyao Li" <xiaoyao.li@intel.com>,
"Thomas Lendacky" <Thomas.Lendacky@amd.com>,
"Eduardo Habkost" <eduardo@habkost.net>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
"Yanan Wang" <wangyanan55@huawei.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH] hw/i386: Add unaccepted memory configuration
Date: Wed, 22 Jun 2022 10:04:07 +0200 [thread overview]
Message-ID: <20220622080407.xnohl6t276cljoik@sirius.home.kraxel.org> (raw)
In-Reply-To: <5d6b2bdb-dc17-2985-c723-9449b40c26f2@amd.com>
Hi,
> AFAIU 'true' is the behavior you are proposing with your EFI changes?
> Saying that what's the difference between 'false' & 'default' wrt EFI
> firmware? Just wondering do we need default?
true/false will force the one or the other no matter what.
'default' allows the firmware to choose depending on various factors,
for example have cc-specific build variants have a different default
behavior than the generic builds.
It also keeps the door open to change default behavior in the future.
One reasonable approach would be to start with firmware accepting all
memory by default, wait until support for unaccepted memory has found
its way into linux distro kernels, then flip the default to pass
unaccepted memory to the linux kernel.
In case the uefi boot service spec gets updated to allow negotiating
unaccepted memory support automatically this can be used easily by
making that the firmware's default behavior.
take care,
Gerd
next prev parent reply other threads:[~2022-06-22 8:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-20 22:33 [PATCH] hw/i386: Add unaccepted memory configuration Dionna Glaze
2022-06-21 5:37 ` Gerd Hoffman
2022-06-21 6:04 ` Michael S. Tsirkin
2022-06-21 10:34 ` Gupta, Pankaj
2022-06-22 8:04 ` Gerd Hoffman [this message]
2022-06-22 8:28 ` Gupta, Pankaj
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=20220622080407.xnohl6t276cljoik@sirius.home.kraxel.org \
--to=kraxel@redhat.com \
--cc=Thomas.Lendacky@amd.com \
--cc=Xu@google.com \
--cc=dionnaglaze@google.com \
--cc=eduardo@habkost.net \
--cc=f4bug@amsat.org \
--cc=marcel.apfelbaum@gmail.com \
--cc=min.m.xu@intel.com \
--cc=mst@redhat.com \
--cc=pankaj.gupta@amd.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=wangyanan55@huawei.com \
--cc=xiaoyao.li@intel.com \
/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).