All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Relph, Richard" <richard.relph@amd.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "Jörg Rödel" <joro@8bytes.org>,
	coconut-svsm@lists.linux.dev, linux-coco@lists.linux.dev
Subject: Re: SVSM Development Call July 2nd, 2025
Date: Wed, 9 Jul 2025 07:04:14 -0500	[thread overview]
Message-ID: <6f263fbd-3049-4961-bc23-25d74396b48c@amd.com> (raw)
In-Reply-To: <aq6225hfazqsbqgx6fhj2klst52wdfivfa6xj2ost65sg5fq2r@4yoqnv2tp5nm>



On 7/9/2025 4:43 AM, Gerd Hoffmann wrote:
>>> I assume you mean dynamic at boot time?
>>
>> Jon Lange should weigh in here... he's the expert on this.
>> But I believe it would need to be dynamic at run-time.
> 
> i.e. support for SVSM_CORE_DEPOSIT_MEM ?
> 
>> Being able start with a "reasonable" amount for page state while
>> allowing for expansion later if needed is the preferred solution.
> 
> What events would trigger the need for expansion?  Would OVMF (which
> typically would run for a few seconds at boot) need to support that?
> Or is that something only the linux kernel (or other guest kernels)
> would have to worry about?

I doubt OVMF would need to worry about it. It feels likely to me that whatever "reasonable" amount we have SVSM pre-allocate would cover whatever page state transitions OVMF might create.

Richard

  reply	other threads:[~2025-07-09 12:04 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-01 20:18 SVSM Development Call July 2nd, 2025 Jörg Rödel
2025-07-04  8:12 ` Jörg Rödel
2025-07-04 10:36   ` Gerd Hoffmann
2025-07-04 16:39     ` Jörg Rödel
2025-07-07 13:50       ` Relph, Richard
2025-07-08 14:12         ` Gerd Hoffmann
2025-07-08 15:12           ` Relph, Richard
2025-07-09  9:43             ` Gerd Hoffmann
2025-07-09 12:04               ` Relph, Richard [this message]
2025-07-10  4:32               ` [EXTERNAL] " Jon Lange
2025-07-11 13:30                 ` Gerd Hoffmann
2025-07-11 17:24                   ` Jon Lange
2025-07-14 10:49                     ` Gerd Hoffmann
2025-07-14 16:18                       ` Jon Lange
2025-07-15 15:07                         ` Gerd Hoffmann
2025-07-15 17:18                           ` Jon Lange
2025-07-09 12:02             ` Jörg Rödel
2025-07-09 12:20               ` Relph, Richard

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=6f263fbd-3049-4961-bc23-25d74396b48c@amd.com \
    --to=richard.relph@amd.com \
    --cc=coconut-svsm@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=kraxel@redhat.com \
    --cc=linux-coco@lists.linux.dev \
    /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.