在 arm 虚拟化的情况下，TTBR0/1 与多个来宾的状态 [英] state of TTBR0/1 wrt to multiple guests in case of virtualization in arm

问题描述

TTBR0/1 是 CP15 寄存器，由 PL1 OS 编程.现在，如果 PL1 OS1 编程 TTBR0，然后在同一内核上调度 PL1 OS2，PL1 OS2 会看到 TTBR0/1 的值设置 OS1

TTBR0/1 are CP15 registers which are programmed by PL1 OS. Now If PL1 OS1 programs TTBR0 and then on the same core the PL1 OS2 is scheduled, would the PL1 OS2 see the value of TTBR0/1 set the OS1

我确信有某种方式可以保持理智，以下是否正确?

I am sure there is someway that the sanity is maintained, is the following is true?

在来宾之间切换时，管理程序将所有 cp15 regs 保存在来宾上下文中，稍后在切换来宾之前恢复

While switching between guests the hypervisor saves all cp15 regs in guest context and later restores before switching the guest

如果是，那么管理程序不会很耗时，因为 cp15 regs 的列表会很长

if yes then wouldnt it be time consuming for hypervisor as the list of cp15 regs would be very long

推荐答案

您可以阅读 ARMv7-AR 架构参考手册中的寄存器说明 - 可从 此处.

You can read the description of the registers in the ARMv7-AR Architecture Reference Manual - downloadable with registration from here.

总而言之，是的 - TTBR0/TTBR1 仅存在于一个副本(每个)中，在切换来宾时由虚拟机管理程序更新.管理程序本身具有供自己使用的 VTTBR.这当然是可以接待无限数量客人的唯一方法.(AArch64 模型有些不同，但相同的基本事实仍然成立.)

In summary, yes - TTBR0/TTBR1 exist in only one copy (each), which is updated by the hypervisor when switching guests. The hypervisor itself has the VTTBR for its own use. This is of course the only way it is possible to host an unlimited number of guests. (The AArch64 model is somewhat different, but the same basic fact remains true.)

显然，这是一项代价高昂的操作，而且不是切换客人所需的唯一操作，因此您当然不想过于频繁地执行此操作.但是需要保留的寄存器列表可能比您想象的要短.

Clearly this is a costly operation, and not the only one required on switching guests, so you certainly don't want to do it too frequently. But the list of registers that need preserving may be shorter than you think.

你可以看到 KVM 的实际实现 此处.

You can see the actual implementation for KVM here.

这篇关于在 arm 虚拟化的情况下，TTBR0/1 与多个来宾的状态的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！