之前介紹了CCA設計的一個目的是讓hypervisor可以創建和調度RME虛擬機和vCPU，并且給它分配內存等資源，但是一旦這些資源分配給RME虛擬機之后，hypervisor就失去了訪問這些RME所有的內存內容的權限。這是通過EL3的monitor軟件修改GPT表項實現的。從而實現虛擬機的機密計算。

Arm和開源社區提供一個參考設計，其中包括包括：

１. Linux kernel KVM模塊的支持：

• 支持由RME通過RMI接口創建，運行虛擬機vCPU，可以服務RME虛擬的RIS host call
• 增加了KVM UABI用于管理Realms
• 增加了Linux kernel作為CCA的Host, 也可以做為CCA的Guest（運行于RME虛擬機，支持RSI接口）

目前運行hypervisor的host Linux運行在non secure EL2, 并且運行于VHE模式。

２. 開源的RMM實現：TF-RMM，主要是服務host hypervisor發過來的RMI請求，創建在Realm狀態下對應host Linux KVM里struct kvm的虛擬機的描述和狀態，和對應host Linux vCPU的虛擬CPU狀態和上下文的結構，并且負責Realm中vCPU的context的save/restore. RMM還負責通過Realm的stage 2實現多個Realm虛擬機間的隔離。

３. 擴展現有的 Arm Trusted Firmware，使它支持RME引入的４個secure狀態和它們間切換時的context swithing，增加了RMI調用的支持和GPT頁表的管理。

TF-RMM采用了類似Hafnium, OPTEE的工作方式，主要目的是將原來在host Linux kernel做的部分事情（如和vCPU context，stage 2頁表配置相關的）通過RMI調用轉到Realm world實現，這部分事情放在host Linux中的話，可以導致host可以獲得修改VM的信息和控制VM的執行。但是TF-RMM和Hafnium, OPTEE一樣沒有調度和復雜的內存管理功能，TF-RMM的執行主要是服務Host Linux的RMI調用和Guest Linux的RSI調用。

概況

Host Linux支持創建普通的虛擬機和Realm虛擬機，現有的KVM API還是可以使用。Host Linux通過KVM_CAP_ARM_RME告訴user space的VMM，平臺是否支持RME的KVM。如果要創建Realm虛擬機，VMM可以通過kvm module的ioctl KVM_ENABLE_CAP調用并傳入.cap = KVM_CAP_ARM_RME參數。Host Linux kernel為之創建的struct kvm結構中的kvm->arch.is_realm記錄，后面kernel通過kvm_is_realm（kvm）檢查是否為Realm VM. KVM_CAP_ARM_RME會導致KVM調用kvm_create_realm->realm_create_rd->rmi_realm_create 這會引起RMI Realm.Create的SMC調用，ATF會將這個調用dispatch給TF-RMM處理，TF-RMM會為之創建Realm Descriptor (RD，struct rd)的結構，對應于host Linux kernel的struct kvm結構。TF-RMM的rmm_handler通過一下handler來服務這些RMI調用：

static const struct smc_handler smc_handlers[] = {
    HANDLER(VERSION,        0, 0, smc_version,         true, true),
    HANDLER(FEATURES,        1, 1, smc_read_feature_register, true,  true),
    HANDLER(GRANULE_DELEGATE,    1, 0, smc_granule_delegate,     false, true),
    HANDLER(GRANULE_UNDELEGATE,    1, 0, smc_granule_undelegate,     false, true),
    HANDLER(REALM_CREATE,        2, 0, smc_realm_create,         true,  true),
    HANDLER(REALM_DESTROY,        1, 0, smc_realm_destroy,     true,  true),
    HANDLER(REALM_ACTIVATE,        1, 0, smc_realm_activate,     true,  true),
    HANDLER(REC_CREATE,        3, 0, smc_rec_create,         true,  true),
    HANDLER(REC_DESTROY,        1, 0, smc_rec_destroy,         true,  true),
    HANDLER(REC_ENTER,        2, 0, smc_rec_enter,         false, true),
    HANDLER(DATA_CREATE,        5, 0, smc_data_create,         false, false),
    HANDLER(DATA_CREATE_UNKNOWN,    3, 0, smc_data_create_unknown,     false, false),
    HANDLER(DATA_DESTROY,        2, 0, smc_data_destroy,         false, true),
    HANDLER(RTT_CREATE,        4, 0, smc_rtt_create,         false, true),
    HANDLER(RTT_DESTROY,        4, 0, smc_rtt_destroy,         false, true),
    HANDLER(RTT_FOLD,        4, 0, smc_rtt_fold,         false, true),
    HANDLER(RTT_MAP_UNPROTECTED,    4, 0, smc_rtt_map_unprotected,     false, false),
    HANDLER(RTT_UNMAP_UNPROTECTED,    3, 0, smc_rtt_unmap_unprotected, false, false),
    HANDLER(RTT_READ_ENTRY,        3, 4, smc_rtt_read_entry,     false, true),
    HANDLER(PSCI_COMPLETE,        2, 0, smc_psci_complete,     true,  true),
    HANDLER(REC_AUX_COUNT,        1, 1, smc_rec_aux_count,     true,  true),
    HANDLER(RTT_INIT_RIPAS,        3, 0, smc_rtt_init_ripas,     false, true),
    HANDLER(RTT_SET_RIPAS,        5, 0, smc_rtt_set_ripas,     false, true)

然后VMM通過KVM_CREATE_VCPU的kvm ioctl調用kvm_vm_ioctl_create_vcpu ->kvm_arch_vcpu_create創建了vCPU之后，對于Realm VMh還需要通過KVM_ARM_VCPU_FINALIZE kvm_arch_vcpu_ioctl系統調用， kvm_arm_vcpu_finalize kvm_create_rec－>rmi_rec_create, 通過RMI REC_CREATE調用（通過SMC指令）到ATF，ATF再將此調用dispatch到TF-RMM，TF-RMM通過smc_rec_create在Realm狀態創建對應于host Linux KVM struct kvm_vcpu的struct rec結構體。Host kernel KVM通過vcpu_is_rec()檢查vCPU是否運行在Realm中。

struct rec {
    struct granule *g_rec;    /* the granule in which this REC lives */
    unsigned long rec_idx;    /* which REC is this */
    bool runnable;

    unsigned long regs[31];

    /*
     * PAuth state of Realm.
     * Note that we do not need to save NS state as EL3 will save this as part of world switch.
     */
    struct pauth_state pauth;

    unsigned long pc;
    unsigned long pstate;

    struct sysreg_state sysregs;
    struct common_sysreg_state common_sysregs;

    struct {
        unsigned long start;
        unsigned long end;
        unsigned long addr;
        enum ripas ripas;
    } set_ripas;
    /*
     * Common values across all RECs in a Realm.
     */
    struct {
        unsigned long ipa_bits;
        int s2_starting_level;
        struct granule *g_rtt;
        struct granule *g_rd;
        bool pmu_enabled;
        unsigned int pmu_num_cnts;
        bool sve_enabled;
        uint8_t sve_vq;
    } realm_info;

    struct {
        /*
         * The contents of the *_EL2 system registers at the last time
         * the REC exited to the host due to a synchronous exception.
         * These are the unsanitized register values which may differ
         * from the value returned to the host in rec_exit structure.
         */
        unsigned long esr;
        unsigned long hpfar;
        unsigned long far;
    } last_run_info;

    /* Pointer to per-cpu non-secure state */
    struct ns_state *ns;

    struct {
        /*
         * Set to 'true' when there is a pending PSCI
         * command that must be resolved by the host.
         * The command is encoded in rec- >regs[0].
         *
         * A REC with pending PSCI is not schedulable.
         */
        bool pending;
    } psci_info;

    /* Number of auxiliary granules */
    unsigned int num_rec_aux;

    /* Addresses of auxiliary granules */
    struct granule *g_aux[MAX_REC_AUX_GRANULES];
    struct rec_aux_data aux_data;

    unsigned char rmm_realm_token_buf[SZ_1K];
    size_t rmm_realm_token_len;

    struct token_sign_ctx token_sign_ctx;

    /* Buffer allocation info used for heap init and management */
    struct {
        struct buffer_alloc_ctx ctx;
        bool ctx_initialised;
    } alloc_info;

    struct {
        unsigned long vsesr_el2;
        bool inject;
    } serror_info;

    /* True if host call is pending */
    bool host_call;
};

然后VMM通過KVM_RUN 的ioctl運行vCPU，對于Realm VM, 這是通過kvm_arch_vcpu_ioctl_run ->kvm_rec_enter->rmi_rec_enter，rmi_rec_enter通過RMI REC_ENTER的調用（通過SMC指令）到ATF，ATF將它dispatch到TF-RMM，TF-RMM調用smc_rec_enter，然后通過rec_run_loop將物理CPU的執行轉交給Realm EL0&EL1的Realm VM。

完整的vCPU運轉圖如下：

由此看出，對于host Linux KVM, 與正常的KVM VM, pKVM VM類似，Realm虛擬機的vCPU的創建是由host Linux上的VMM管理的，每個Realm vCPU對于host Linux來說也只是VM進程的一個線程，也是由host Linux負責調度的。只是Realm vCPU運行于Realm EL0&EL1狀態。但是Realm VM和Realm vCPU的信息host Linux是看不到的，這點與正常的KVM VM不同。

從上圖也可以看出，Realm vCPU執行的進入和退出需要經過更長的路徑，如進入vCPU的執行需要經過host Linux KVM->ATF->TF-RMM->Realm VM,每個步驟都涉及到context save/restore. 但根據初步的研究發現，這個過程中帶來的overhead并不是很明顯。

Stage 2 table的管理

RMM的stage 2用于Realm VM之間的隔離。在TF-RMM中維護一個RTT，相當于Normal KVM VM中的stage 2頁表，對于Realm VM, 這是由TF－RMM管理的RTT.
Realm VM的IPA空間包括一個受保護的地址范圍(PAR)，RMM確保只能將其映射到Realm PAS。

對于在PAR內的訪問，RMM保證給Realm的機密性和完整性；在PAR之外，hypervisor可以自由地映射NS PAS內存頁或模擬訪問。這為在Realm VM上運行的OS提供了一個可靠的機制來確定它是訪問自己的私有內存，還是可以與不受信任的其他部分共享的內存。

在Realm創建期間，hypervisor可以將一個內存頁分配給Realm，在PAR內的特定IPA處，并從NS內存頁復制數據到它。IPA和數據經過加密哈希，哈希包含在Realm的認證令牌中。認證令牌允許Realm的所有者推理其初始狀態和內容。一旦Realm被激活，只能將內存添加到其他未使用的IPA。

hypervisor可以隨時從Realm回收內存。RMM在回收內存頁并將其返回給hypervisor之前將此內存頁清零。后續訪問Realm回收內存的IPA會導致RMM的stage 2異常，這會阻止Realm進一步執行并保持Arm CCA的完整性保證。

在Host Linux KVM中它可以請求map或是unmap Realm VM的stage 2映射，讓RMM管理Realm stage 2頁表，但它不能獲取修改到Realm RMM的stage 2頁表內容。例如Host Linux KVM可以通過unmap_stage2_range來請求unmap一些stage 2映射，這個過程是：

unmap_stage2_range- >__unmap_stage2_range- >kvm_realm_unmap_range- >realm_tear_down_rtt_range,

在這里會通過RMI的RTT_DESTROY，RTT_CREAT調用（通過SMC指令）到ATF, ATF再將它dispatch到TF-RMM的smc_rtt_create，smc_rtt_create進行RMM RTT頁表操作。

中斷處理

目前沒有GIC沒有專門對Realm VM的虛擬中斷支持，因此Realm VM的中斷需要在host Linux kernel中通過其vgic中斷產生虛擬中斷。

由代碼可知，RMM在rec_run_loop中準備運行Realm時（參見前面Realm vCPU運行流程圖），它調用restore_realm_state

static void restore_realm_state(struct rec *rec)
{
    write_cnthctl_el2(rec- >sysregs.cnthctl_el2);
    isb();

    restore_sysreg_state(&rec- >sysregs);

    write_elr_el2(rec- >pc);
    write_spsr_el2(rec- >pstate);
    write_hcr_el2(rec- >sysregs.hcr_el2);

設置Realm EL2的HCR_EL2寄存器的值為

HCR_FLAGS     (HCR_FWB | HCR_E2H | HCR_RW | HCR_TSC | HCR_AMO |HCR_BSU_IS | HCR_IMO | HCR_FMO | HCR_PTW | HCR_SWIO | HCR_VM | HCR_TID3 | HCR_TEA | HCR_API | HCR_APK)

這個設置中HCR_IMO, HCR_FMO讓當運行在Realm EL0&EL1 （Realm VM)時產生的IRQ和FIQ會route到Realm EL2 (RMM)中處理。
RMM對于這些route到Realm EL2的處理為

el2_irq_lel:
    stp    x0, x1, [sp, #-16]!
    mov    x0, #ARM_EXCEPTION_IRQ_LEL
    b    realm_exit
ENDPROC(el2_sync_lel)

el2_fiq_lel:
    stp    x0, x1, [sp, #-16]!
    mov    x0, #ARM_EXCEPTION_FIQ_LEL
    b    realm_exit
ENDPROC(el2_sync_lel)

realm_exit使執行回到handle_realm_exit，然后繼續退回到ATF，ATF繼續退回到Host Linux KVM, 再在host Linux kernel里進行這個物理中斷的處理，如果要產生一個虛擬中斷給Realm VM，host Linux kernel利用其GIC driver的vGIC產生一個虛擬中斷，然后通過ATF進入到RMM，RMM再回到Realm VM的執行，這是Realm VM就能處理這個pending的虛擬中斷。

ATF的支持

ATF對CCA支持主要包括：
１. 加載RMM Image和啟動RMM

２. 負責Root，Non Secure，Secure和Realm四個secure world的切換，增加了RMM的dispatcher

３. 管理GPT頁表

Host Linux KVM可以通過alloc_delegated_page ，free_delegated_page 等函數來請求ATF改變一個物理內存頁在GPT頁表中的PAS, 這是通過host Linux kvm調用rmi_granule_delegate， rmi_granule_undelegate也就是RMI GRANULE_UNDELEGATE ，RMI GRANULE_UNDELEGATE的RMI調用(通過SMC指令)，這會進入到ATF的rmmd_rmi_handler進行處理，它將這個RMI請求forward到RMM中處理，RMM處理之后，RMM可以調用RMM_GTSI_DELEGATE或SMC_RMM_GTSI_UNDELEGATE調用（通過SMC）回到ATF，在ATF中的rmmd_rmm_el3_handler中調用gpt_delegate_pas或是gpt_undelegate_pas來修改GPT頁表，最終修改了此物理頁對應的PAS。

不受信任的hypervisor總能停止調度一個Realm，并總是可以回收分配給Realm的內存，但在任何情況下，它都不能訪問Realm的CPU或內存狀態。這是通過一個簡單但功能強大delegate(分批/委托)來實現的。hypervisor將內存delegate給Realm world，和回收到non secure world。所有由Realms使用的內存首先必須由hypervisor delegate；RMM本身不管理Realm的內存池。

一旦內存被delegate給Realm world，hypervisor可以請求RMM將其用于各種目的，例如保存Realm的元數據或數據。當一個內存頁被delegate給Realm world但未被RMM使用時，RMM確保該內存頁清零，從而降低了內存頁被重用或回收時意外信息泄露風險。

RMM為hypervisor提供了一個Realm管理接口(RMI)，要求RMM delegate內存、創建Realms、執行Realms和為Realms分配內存。每一個RMI命令都是作為一個SMC實現的，所以當hypervisor調用該命令時，它會陷入到EL3 Monitor，然后切換執行到Realm world的RMM來處理命令。在RMI命令完成后，RMM向EL3 Monitor發出一個SMC，將執行切換回NS world的hypervisor。

為了維護Realms的安全保證，RMM必須知道系統上每個內存頁的狀態，它通過維護自己的內存頁狀態表(GST)來實現，以跟蹤每個內存頁的delegate狀態和使用情況。當hypervisor delegate一個內存頁時，RMM檢查其GST，以確認內存頁尚未被delegate，RMM然后向EL3 Monitor發出一個SMC請求更改Realm PAS。

EL3 Monitor檢查該內存頁當前是否位于NS PAS，然后更新GPT將其移至Realm PAS。最后，RMM更新其GST以記錄該內存頁已被delegate。如果hypervisor試圖delegate已被delegate的內存頁，或回收RMM正在使用的內存頁，RMM會返回一個錯誤代碼給不受信任的hypervisor。與GPT不同，GST不是由硬件檢查的，而只是一個軟件記錄機制。

目前的限制

1. 目前沒有GIC沒有專門對Realm VM的虛擬中斷支持，因此Realm VM的中斷需要在host Linux kernel中通過其vgic中斷產生虛擬中斷。未來的GIC會支持Realm虛擬中斷的注入
2. 暫時沒有 Device Assignment的支持，隨著SMMU的進化和軟件的開放，后面會支持
3. 目前在arm構架上的KVM有四種不同的支持方式：armv7-a/armv8.0-a的KVM支持方式，自armv8.1-a開始支持的VHE方式，Google推的pKVM方式，Realm支持的方式。軟件構架上需要提供更clear的實現。