Steps towards live migration

Jakub Růžička <[email protected]> Fri, 27 Jun 2025 15:45:56 +0200
Newsgroups	dev.linux.lists.coconut-svsm
Message-ID	<[email protected]>
Hi,

as mentioned during the last SVSM development talk, I am currently writing my
thesis on live migration of confidential guests. With this email I would like to
start a discussion so that the same problem is not addressed multiple times
independently. I also welcome any feedback to make the code written useful for
SVSM Coconut (not only for the thesis). Development is done on machine with
SEV-SNP support. I made a pull request with the SVSM patches[1] to ease the
discussion.

Here is a summary of progress to date:

All validated guest pages can be transferred from the source SVSM to the target
SVSM. Currently, no packaging (no confidentiality) is performed, but a hash of
all transferred/received blocks is computed that can be compared to verify that
the channel is working correctly. Also, the main migration function of the
source and destination SVSM is busy waiting for a signal from QEMU to start
outbound or incoming migration.

A single shared page called MigrationPage is used for data transfer and
communication with QEMU. The migration page contains two registers and a buffer:
a status register, a data register, and a data buffer. The status register is
used to signal a change in status (e.g., migration starts, migration is
complete). The data register is used to signal that a new page has been prepared
in the data buffer by the provider or processed by the consumer. The roles of
provider and consumer are switched between SVSM and QEMU on the source and
destination machines.

The QEMU patch[2] implements communication with the SVSM migration handler and
block transfer from source to destination. The idea is that creating the
communication channel is all the hypervisor should do, the rest should be done
in SVSM.

Current plan for the future in order of realisation:

(1) A function that puts all hosted vCPUs (except the migration handler) into a
    spinning state. The hypervisor is not trusted, so the SVSM must be able to
    ensure that it is not running any vCPUs. For this task, I consider two-phase
    checkpointing[3].
(2) Migrate the machine from the source to the destination with all vCPUs 
    stopped by the function from (1).
(3) Secret key establishment - though about using [5].
(4) Package the pages - authenticated encryption using [4].
(5) Dirty page tracking.
(6) Move the SVSM migration handler on an extra vCPU.
(7) Start migration handler on signal instead of busy-waiting loop.

Best regards,
Jakub

[1] https://github.com/coconut-svsm/svsm/pull/745
[2] https://github.com/coconut-svsm/qemu/pull/23
[3] https://ipads.se.sjtu.edu.cn/_media/publications/sgxmigration-dsn17.pdf
[4] https://github.com/RustCrypto/AEADs/blob/master/aes-gcm/src/lib.rs
[5] https://github.com/nihalpasham/static-dh-ecdh
signature.asc (application/pgp-signature, 228 B)