From: "Michael S. Tsirkin" <mst@redhat.com>
To: Gerd Hoffman <kraxel@redhat.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>
Subject: Re: [PATCH] hw/i386: Add unaccepted memory configuration
Date: Tue, 21 Jun 2022 02:04:37 -0400 [thread overview]
Message-ID: <20220621020150-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20220621053702.oqzkmij4b4jm4ysd@sirius.home.kraxel.org>
On Tue, Jun 21, 2022 at 07:37:02AM +0200, Gerd Hoffman wrote:
> On Mon, Jun 20, 2022 at 10:33:00PM +0000, Dionna Glaze wrote:
> > For SEV-SNP, an OS is "SEV-SNP capable" without supporting this UEFI
> > v2.9 memory type. In order for OVMF to be able to avoid pre-validating
> > potentially hundreds of gibibytes of data before booting, it needs to
> > know if the guest OS can support its use of the new type of memory in
> > the memory map.
>
> I think this should be wired up via sev-guest object (see
> SevGuestProperties in qapi/qom.json and target/i386/sev.c),
> i.e.
>
> qemu -object sev-guest,accept-all-memory=true,$args
>
> (and likewise for -object tdx-guest once merged).
>
> take care,
> Gerd
Right. As written the patch would allow the flag without SEV-SNP too -
but does it make any sense outside SEV-SNP? It's better not to allow
flag combinations that make no sense since they tend to
become part of ABI that we then need to support.
--
MST
next prev parent reply other threads:[~2022-06-21 6: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 [this message]
2022-06-21 10:34 ` Gupta, Pankaj
2022-06-22 8:04 ` Gerd Hoffman
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=20220621020150-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=Thomas.Lendacky@amd.com \
--cc=Xu@google.com \
--cc=dionnaglaze@google.com \
--cc=eduardo@habkost.net \
--cc=f4bug@amsat.org \
--cc=kraxel@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=min.m.xu@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.