From: Xiaoyao Li <xiaoyao.li@intel.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "Xu, Min M" <min.m.xu@intel.com>,
Dionna Amalie Glaze <dionnaglaze@google.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 10:53:46 +0800 [thread overview]
Message-ID: <503fadf7-c6d1-61dd-236e-fcca895e8aef@intel.com> (raw)
In-Reply-To: <20220616082846.wtmf3wbxzilzvqt4@sirius.home.kraxel.org>
On 6/16/2022 4:28 PM, Gerd Hoffmann wrote:
> Hi,
>
>> After re-read and re-think, I think the problem is better to state as: we
>> need an interface for QEMU to tell OVMF how much memory it needs to accept,
>> from [Minimum to All]. So for the case that user wants to boot an
>> partial-enabled confidential VMs (like current Linux TDX and SNP guest),
>> user needs to specify from QEMU to tell OVMF to accept all the memory.
>
> Asking the user to manually configure stuff sucks, that's why I think
> it makes sense to let firmware and guest negotiate this automatically.
>
> That doesn't work today though, so we will need some config option
> indeed.
>
> The proposal in the parallel thread is to just accept all low memory
> (below 4G) unconditionally. So maybe it is enough to have:
>
> * 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
>
> ... once the automatic negotiation is available.
IMO, basically, we need two options:
1. accept all memory, for the case that guest OS cannot handle
unaccepted memory;
2. accept minimal memory, for the case that guest OS is capable of
accepting memory.
Accepting memory is time consuming. To save as much time as possible,
OVMF only needs to accept:
a. the enough memory for its own code running;
b. the enough memory for guest OS to setup everything ready to accept
memory on guest own. e.g.,
i. the memory where guest kernel locates;
ii. the stack/heap/memory buffer, from which guest kernel needs
to allocate memory
As long as both a) and b) are meet, we can accept as less as possible
to save the time OVMF is running.
Min did some POC on this for TDX, that accepts 256M/128M (I don't
remember the exact number) in OVMF for guest kernel to operate
normally and guest can accept remaining unaccepted memory on its own.
More flexible, we can provide a 3) option, that guest tells OVMF the GPA
ranges that need to be accepted by OVMF.
> take care,
> Gerd
>
next prev parent reply other threads:[~2022-06-17 2:55 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 [this message]
2022-06-17 19:57 ` Dionna Amalie Glaze
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=503fadf7-c6d1-61dd-236e-fcca895e8aef@intel.com \
--to=xiaoyao.li@intel.com \
--cc=Thomas.Lendacky@amd.com \
--cc=dionnaglaze@google.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 \
/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).