qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Dionna Amalie Glaze <dionnaglaze@google.com>
To: Xiaoyao Li <xiaoyao.li@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>,
	"Xu, Min M" <min.m.xu@intel.com>,
	 "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"Lendacky, Thomas" <Thomas.Lendacky@amd.com>,
	 "Yao, Jiewen" <jiewen.yao@intel.com>,
	"Aktas, Erdem" <erdemaktas@google.com>,
	 "Yamahata, Isaku" <isaku.yamahata@intel.com>
Subject: Re: New "IndustryStandard" fw_cfg?
Date: Fri, 17 Jun 2022 12:57:52 -0700	[thread overview]
Message-ID: <CAAH4kHYK5XRUvUC3-QeRuFGn1uTu6LJ=TOHik_oOqw0PSYoKOw@mail.gmail.com> (raw)
In-Reply-To: <503fadf7-c6d1-61dd-236e-fcca895e8aef@intel.com>

I think the option should be boolean since it doesn't look like we're
going to need to tune the number very much.
It all boils down to "does the OS affirmatively support unaccepted
memory?" as in, we have no way to negotiate it, but force unaccepted
memory on.
Ovmf can interpret the existence of an opt/ovmf/unaccepted_memory file
to mean that it's allowed to create unaccepted memory entries in the
memory map.
It's then up to the firmware if it will minimize its use of unaccepted
memory or not. It's not Qemu's place to say.


> >    * accept all memory below 4G
> >    * accept all memory
> >
> > Possibly we need:
> >
> >    * accept all memory below 4G
> >    * accept all memory below 4G, plus x GB of high memory.
> >    * accept all memory
> >
> > In any case the config option should be designed in a way that we can
> > add a 'automatic' choice later, i.e. we can have ...
> >
> >    * automatic (default)
> >    * accept all memory below 4G
> >    * accept all memory
> >

I think "false" can mean either accept all memory or "do what you need
to" and negotiate if the memory map boot service can create unaccepted
memory entries. Whichever appears supported.
Then "true" can be "do whatever, including creating unaccepted memory
entries in the memory map".

That seems the simplest way to allow a configuration of this feature.

-- 
-Dionna Glaze, PhD (she/her)


  reply	other threads:[~2022-06-17 19:59 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-14 18:08 New "IndustryStandard" fw_cfg? Dionna Amalie Glaze
     [not found] ` <PH0PR11MB50643B5AEE5A399EB8AFB000C5AD9@PH0PR11MB5064.namprd11.prod.outlook.com>
2022-06-15  7:33   ` Gerd Hoffmann
2022-06-15 19:23     ` Dionna Amalie Glaze
2022-06-15 15:19   ` Xiaoyao Li
2022-06-15 16:51     ` Tom Lendacky
2022-06-16  5:37     ` Gerd Hoffmann
2022-06-16  5:49       ` Xiaoyao Li
2022-06-16  6:00         ` Gerd Hoffmann
2022-06-16  6:33   ` Xiaoyao Li
2022-06-16  8:28     ` Gerd Hoffmann
2022-06-17  2:53       ` Xiaoyao Li
2022-06-17 19:57         ` Dionna Amalie Glaze [this message]
2022-06-20 10:42           ` Gerd Hoffmann

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='CAAH4kHYK5XRUvUC3-QeRuFGn1uTu6LJ=TOHik_oOqw0PSYoKOw@mail.gmail.com' \
    --to=dionnaglaze@google.com \
    --cc=Thomas.Lendacky@amd.com \
    --cc=erdemaktas@google.com \
    --cc=isaku.yamahata@intel.com \
    --cc=jiewen.yao@intel.com \
    --cc=kraxel@redhat.com \
    --cc=min.m.xu@intel.com \
    --cc=qemu-devel@nongnu.org \
    --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).