Am 05.10.21 um 15:26 schrieb Janosch Frank:
On 9/20/21 15:24, Claudio Imbrenda wrote:
Previously, when a protected VM was rebooted or when it was shut down,
its memory was made unprotected, and then the protected VM itself was
destroyed. Looping over the whole address space can take some time,
considering the overhead of the various Ultravisor Calls (UVCs). This
means that a reboot or a shutdown would take a potentially long amount
of time, depending on the amount of used memory.
This patchseries implements a deferred destroy mechanism for protected
guests. When a protected guest is destroyed, its memory is cleared in
background, allowing the guest to restart or terminate significantly
faster than before.
There are 2 possibilities when a protected VM is torn down:
* it still has an address space associated (reboot case)
* it does not have an address space anymore (shutdown case)
For the reboot case, the reference count of the mm is increased, and
then a background thread is started to clean up. Once the thread went
through the whole address space, the protected VM is actually
destroyed.
This means that the same address space can have memory belonging to
more than one protected guest, although only one will be running, the
others will in fact not even have any CPUs.
The shutdown case is more controversial, and it will be dealt with in a
future patchseries.
When a guest is destroyed, its memory still counts towards its memory
control group until it's actually freed (I tested this experimentally)
@Christian: I'd like to have #1-3 in early so we can focus on the more complicated stuff.
Yes, makes perfect sense.
