Re: SVSM Development Call July 2nd, 2025

["Relph, Richard" <richard.relph@amd.com>]

On 7/9/2025 7:02 AM, Jörg Rödel wrote:
> Hi Richard,
> 
> On Tue, Jul 08, 2025 at 10:12:09AM -0500, Relph, Richard wrote:
>> Jon Lange should weigh in here... he's the expert on this.
>> But I believe it would need to be dynamic at run-time.
>> Using 'worst case' allocations that might have every page ending up needing
>> it's own page state entry leads to excessive memory reservations. While not
>> having enough memory leads to fatal errors. Being able start with a
>> "reasonable" amount for page state while allowing for expansion later if
>> needed is the preferred solution. At least that's what I was hearing last
>> Wednesday.
> 
> I think it is reasonable to assume that the (Linux) guest will eventually use
> all available memory, and thus it makes sense to allocate the page-state
> tracking data structure(s) big enough to cover all all guest memory right from
> the start.
> 
> This eliminates the need for runtime resizing of SVSM memory, which is also
> only possible on platforms/configurations that use the SVSM protocol.

A "one entry for every page" approach to the page state tracking information might be pretty large, worst case. I'd have to replay the conversation from last week, but my sense was there's a fair bit of information that might eventually want to be known about each page. Some form of compression feels appropriate, since adjacent pages will often have identical state. But, worst case, every page could have different state, especially as the information about each page grows.

But we've stretched beyond my understanding of all the kinds of information that we might want to track from SVSM. Jon and others would need to chime in. For my immediate needs (rebooting a guest from SVSM), all I need is one bit per page... and I was considering run-length encoding that since it feels to me at this point like OVMF and Linux both do SVSM validate operations on large contiguous blocks of pages.

I agree, though, that if the long-term goal of SVSM is to be able to support guest OSs that are blissfully ignorant of SNP and SVSM, we can't rely on the guest OS to cooperate and a worst-case pre-allocation would be required, absent a way to get more from the host OS.

Richard

> 
> Regards,
> 
>         Joerg