lkml.org 
[lkml]   [2024]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] driver/virtio: Add Memory Balloon Support for SEV/SEV-ES
From
On 10.01.24 07:22, Zheyun Shen wrote:
> For now, SEV pins guest's memory to avoid swapping or
> moving ciphertext, but leading to the inhibition of
> Memory Ballooning.
>
> In Memory Ballooning, only guest's free pages will be relocated
> in balloon inflation and deflation, so the difference of plaintext
> doesn't matter to guest.

A Linux hypervisor will always give you a fresh, zeroed page. I don't
recall what the spec says, could be that that is a guarantee.

>
> Memory Ballooning is a nice memory overcommitment technology can
> be used in CVM based on SEV and SEV-ES, so userspace tools can
> provide an option to allow SEV not to pin memory and enable
> Memory Ballooning. Guest kernel may not inhibit Balloon and
> should set shared memory for Balloon decrypted.

Two points:

1) Memory overcommit means that you promise to have more memory than you
actually have.

To be able to use that in a *safe* way in the hypervisor, to fulfill
that promise, you need some backup strategy, which is usually swap space
in the hypervisor. Further one might apply other techniques (ram
compression, memory deduplication) in the hypervisor to make that
swapping unlikely to ever happen when overcommitting (because nobody
wants to swap).

Assume you run a lot of VMs that mostly have private/encrypted memory
(which is the default). Imagine you previously inflated the balloon on
VM0, and that VM needs more memory (you promised it could have more!).
You reach out to other VMs to inflate the balloon so you get memory
back, but they cannot give up memory safely.

In that scenario (a) you cannot swap something out because all pages are
pinned (b) memory compression cannot be applied because pages are pinned
and (c) memory deduplication cannot be applied because pages are pinned.

Pinned memory is a resource that cannot be overcomitted.

So I am not convinced the use case you are targeting can be considered
any way of sane memory overcommit. You should better call it resizing VM
memory instead. Then, it's clearer that the hypervisor cannot promise to
ever give you that memory when you are in need.


2) What about other features?

What if the hypervisor enabled free-page-reporting? Would that work
(unlikely, I assunme). Don't we have to block that?

--
Cheers,

David / dhildenb


\
 
 \ /
  Last update: 2024-01-11 09:36    [W:0.031 / U:0.676 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site