# Live Migration Revision
## 1 Introduction
The contributions can be changed to:
1. the design: defined a set of APIs and architectural requirement used for efficient and secure live migration on generalized confidential computing (TDX, CCA, SEV) platforms and does not break the threat model of them
2. discovered the insufficiency of AMD SEV, a confidential computing architecture claiming live migration support, for it cannot satisfy all the API and architectural requirement
3. implemented live migration support on SeKVM to showcase the benefit and security
4. evaluated 1) the potential performance benefit AMD SEV can get should it satisfy all the requirements; 2) the performance can be achieved on our reference SeKVM implementation without compromising security

## 2 Background
I think we talked too much about current VM live migration. The length of confidential computing platform should be roughly equal to that of VM live migration. We can do the following:

### 2.1 Confidential Virtual Machines
#### 2.1.1 AMD SEV
Talk at a high level about its available APIs and foreshadow that they are not sufficient.

#### 2.1.2 Intel TDX and Arm CCA
Introduce them at a high level and mention that they currently do not have any live migration API support. Foreshadow that our design will not break their secure model while giving performance benefit.

### 2.2 VM Live Migration
This part can stay the same but we should aim at cutting its length to the necessary amount that can describe SEV's deficiency. We can talk about the optimizations in a more general form, saying that they are the most commonly used mechanism in VM live migration (need to look up for more references).

## 3 Design of a Secure and Efficient Confidential Live Migration System
The idea is to make this section the main design section that describe the APIs and architecture **in detail** (as opposed to be at a high level in the original paper):
1. The APIs mentioned original section 3 (Live Migration Mechanism for Confidential VMs). We can talk about some of the SeKVM implementation (original section 5) that can constitute to a general design here
2. A more detailed description of key management
3. Architecture (hw/sw) support that enables post-copy and multifd: e.g. not a single firmware thread, not states whose actions are limited to a point post-copy is impossible, etc
4. Why can this design be compatible to the threat model and security guarantee provided by all three existing confidential VMs

## 4 The Case of Live Migration on AMD SEV
AMD SEV is the one architecture that claims live migration support (need a more thorough survey) but is insufficient to design in section 3. This deficiency will lead to a degradation of performance. This section will talk about the reason (hence the original paper content), and the evaluation section will talk about how much performance is lost.

## 5 Implementation
SeKVM's role should be a **reference implementation** of the design in section 3. I suggest we improve this section as follows:
1. Reduce the amount of implementation detail, and focus on how the APIs is implemented and how the desired architecture is simulated in software
2. A discussion of how SeKVM can be representative of the threat model of all three existing confidential VMs

## 6 Evaluation
Evaluation should be separated into:
### 6.1 SEV vs. Pseudo SEV
The purpose of this section is to demonstrate the performance we can get should SEV be improved to support post-copy & multifd

### 6.2 SeKVM
I feel like currently we have only dumped a lot of numbers and graphs. Would be good if we can have a bullet point or ordered list summarizing the goals of evaluation, and each subsection in 6.2 will evaluate one element in the goal list. I'm not sure how the list should look like since Jian-Lin and Fang-Jie are still working on it, but it might be something like this:
1. The limited overhead compared to vanilla, showing that the reference implementation is performant.
2. Improvement of optimization whose scale is comparable to that of SEV vs. Pseudo SEV, showing that SeKVM is really generalizable.