On Thu, Jun 30, 2022, Will Deacon wrote: > Hi everyone, > > This series has been extracted from the pKVM base support series (aka > "pKVM mega-patch") previously posted here: > > https://lore.kernel.org/kvmarm/20220519134204.5379-1-will@xxxxxxxxxx/ > > Unlike that more comprehensive series, this one is fairly fundamental > and does not introduce any new ABI commitments, leaving questions > involving the management of guest private memory and the creation of > protected VMs for future work. Instead, this series extends the pKVM EL2 > code so that it can dynamically instantiate and manage VM shadow > structures without the host being able to access them directly. These > shadow structures consist of a shadow VM, a set of shadow vCPUs and the > stage-2 page-table and the pages used to hold them are returned to the > host when the VM is destroyed. > > The last patch is marked as RFC because, although it plumbs in the > shadow state, it is woefully inefficient and copies to/from the host > state on every vCPU run. Without the last patch, the new structures are > unused but we move considerably closer to isolating guests from the > host. ... > arch/arm64/include/asm/kvm_asm.h | 6 +- > arch/arm64/include/asm/kvm_host.h | 65 +++ > arch/arm64/include/asm/kvm_hyp.h | 3 + > arch/arm64/include/asm/kvm_pgtable.h | 8 + > arch/arm64/include/asm/kvm_pkvm.h | 38 ++ > arch/arm64/kernel/image-vars.h | 15 - > arch/arm64/kvm/arm.c | 40 +- > arch/arm64/kvm/hyp/hyp-constants.c | 3 + > arch/arm64/kvm/hyp/include/nvhe/gfp.h | 6 +- > arch/arm64/kvm/hyp/include/nvhe/mem_protect.h | 19 +- > arch/arm64/kvm/hyp/include/nvhe/memory.h | 26 +- > arch/arm64/kvm/hyp/include/nvhe/mm.h | 18 +- > arch/arm64/kvm/hyp/include/nvhe/pkvm.h | 70 +++ > arch/arm64/kvm/hyp/include/nvhe/spinlock.h | 10 +- > arch/arm64/kvm/hyp/nvhe/cache.S | 11 + > arch/arm64/kvm/hyp/nvhe/hyp-main.c | 105 +++- > arch/arm64/kvm/hyp/nvhe/hyp-smp.c | 2 + > arch/arm64/kvm/hyp/nvhe/mem_protect.c | 456 +++++++++++++++++- > arch/arm64/kvm/hyp/nvhe/mm.c | 136 +++++- > arch/arm64/kvm/hyp/nvhe/page_alloc.c | 42 +- > arch/arm64/kvm/hyp/nvhe/pkvm.c | 438 +++++++++++++++++ > arch/arm64/kvm/hyp/nvhe/setup.c | 96 ++-- > arch/arm64/kvm/hyp/pgtable.c | 9 + > arch/arm64/kvm/mmu.c | 26 + > arch/arm64/kvm/pkvm.c | 121 ++++- > 25 files changed, 1625 insertions(+), 144 deletions(-) > create mode 100644 arch/arm64/kvm/hyp/include/nvhe/pkvm.h The lack of documentation and the rather terse changelogs make this really hard to review for folks that aren't intimately familiar with pKVM. I have a decent idea of the end goal of "shadowing", but that's mostly because of my involvement in similar x86 projects. Nothing in the changelogs ever explains _why_ pKVM uses shadows. I put "shadowing" in quotes because if the unstrusted host is aware that the VM and vCPU it is manipulating aren't the "real" VMs/vCPUs, and there is an explicit API between the untrusted host and pKVM for creating/destroying VMs/vCPUs, then I would argue that it's not truly shadowing, especially if pKVM uses data/values verbatim and only verifies correctness/safety. It's definitely a nit, but for future readers I think overloading "shadowing" could be confusing. And beyond the basics, IMO pKVM needs a more formal definition of exactly what guest state is protected/hidden from the untrusted host. Peeking at the mega series, there are a huge pile of patches that result in "gradual reduction of EL2 trust in host data", but I couldn't any documentation that defines what that end result is.
