|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [PATCH v4 00/30] ASI: HVM per-vCPU areas, sparse-view directmap, per-vCPU state area
This is the first part of a series to implement address space isolation. The approach is the same as v3: Start by focusing on just getting ASI and intra-domain isolation for HVM guests. PV support is added where it's simple to do, and regressions are avoided. The first 20 patches are (sometimes broken-down or extended) versions of what was posted in v3; the last 10 patches make a few additional improvements to the sparse-view directmap, and then begin moving vCPU state out of the xenheap and into a per-vCPU area. To be more detailed: 01: A fix that should be considered for backport 02-14: Implement per-vCPU perdomain area and per-vCPU mapcaches for HVM guests. 15-22: Maintain two "views" of the directmap: A full directmap, and a sparse directmap. The full directmap is what we have now; the sparse directmap removes non-xenheap heap memory. 23-30: Add a vCPU state area to the perdomain area (both for PV and HVM). Move SVM VMCB structures and VMX guest MSR areas into it. One key thing to get feedback on is 22: It's a not very simple effort to mitigate a very rare event. Note that at the end of this series, PV guests can be given the sparse direct-map; this isolates them from other domains, but doesn't isolate vCPUs within a domain. An advantage of this is that it allows us to easily turn the sparse directmap off for dom0 (or other system domains). Some quick tests on my local test rig on v3 of the series show that network throughput from dom0 to a guest drops 31% when the sparse directmap is enabled for dom0 vs not. The rest of the series looks like this: - Move more things into the vCPU state area: user_regs, FPU/XSAVE - Hardening for ioreq server state (The ioreq server pages can't be moved into per-vCPU areas without a massive refactoring of the ioreq server protocol.) - Implement per-pCPU stacks. In this mode, per-pCPU stacks would only be for HVM guests using the "sparse directmap". Until we get per-vCPU root pagetables for PV guests, it's not practical to prevent a PV guest from seeing all the stacks. - Low-hanging optimizations A dependency graph of the above functionality can be found here: https://xenbits.xenproject.org/people/gdunlap/asi-series-deps.html Extending the intra-domain isolation to PV guests would involve implementing per-vCPU root pagetables for PV guests. There are draft implementations of this, but they are quite complicated. George Dunlap (20): x86/PoD: map one page at a time in p2m_pod_zero_check() x86/mm: refuse to promote an L4 while the domain has no vCPU x86/mm: have init_xen_l4_slots() take a vCPU in place of the domain x86/domain_page: drop redundant is_pv_vcpu() checks x86/domain_page: don't unmap a mapcache entry that is not present x86/mm: let Xen's page-table walker operate on a given root x86/mm: build and maintain a sparse view of the directmap x86/domain_page: key the directmap fast paths on the loaded view x86/domain_page: clear a mapcache slot at its last unmap x86/mm: run guest contexts on the sparse directmap view x86/spec-ctrl: wire the sparse directmap view into the asi= option xen/xmalloc: return an emptied region after dropping the pool lock x86/mm: split a sparse directmap superpage with a page being freed x86/mm: introduce a per-vCPU state window in the perdomain area x86/svm: introduce svm_vmcb_map() and svm_vmcb_unmap() x86/svm: clear the VMCB clean bits in svm_ctxt_switch_from() x86/svm: restore guest debug registers in svm_do_resume() x86/svm: drop svm_vmcb_dump()'s paddr and the unused VCPU_svm_vmcb x86/svm: allocate VMCBs from the domain heap behind the vCPU state window x86/vmx: move the guest MSR load/save list off always-mapped memory Roger Pau Monné (10): x86/mm: purge unneeded destroy_perdomain_mapping() x86/mm: prepare destroy_perdomain_mapping() for per-vCPU perdomain areas x86/domain_page: drop redundant create_perdomain_mapping() call x86/mm: prepare create_perdomain_mapping() for per-vCPU perdomain areas x86/spec-ctrl: introduce Address Space Isolation command line option x86/hvm: introduce per-vCPU L3 page-table x86/domain_page: prepare the mapcache for per-vCPU accounting x86/domain_page: move struct mapcache_vcpu to struct arch_vcpu x86/hvm: introduce per-vCPU mapcache for vCPU-PT domains x86/mm: introduce populate_perdomain_mapping() docs/misc/xen-command-line.pandoc | 49 +++ xen/arch/x86/Kconfig | 1 + xen/arch/x86/Makefile | 1 + xen/arch/x86/domain.c | 30 +- xen/arch/x86/domain_page.c | 302 +++++++++---- xen/arch/x86/hvm/hvm.c | 6 - xen/arch/x86/hvm/svm/nestedsvm.c | 12 +- xen/arch/x86/hvm/svm/svm.c | 151 +++++-- xen/arch/x86/hvm/svm/vmcb.c | 74 +++- xen/arch/x86/hvm/svm/vmcb.h | 20 +- xen/arch/x86/hvm/vmx/vmcs.c | 134 +++++- xen/arch/x86/include/asm/config.h | 23 +- xen/arch/x86/include/asm/domain.h | 51 ++- xen/arch/x86/include/asm/hvm/vmx/vmcs.h | 63 +-- xen/arch/x86/include/asm/mm.h | 29 +- xen/arch/x86/include/asm/sparse-directmap.h | 83 ++++ xen/arch/x86/include/asm/spec_ctrl.h | 2 + xen/arch/x86/mm.c | 424 +++++++++++++++--- xen/arch/x86/mm/hap/hap.c | 2 +- xen/arch/x86/mm/p2m-pod.c | 72 ++-- xen/arch/x86/mm/shadow/hvm.c | 2 +- xen/arch/x86/mm/shadow/multi.c | 2 +- xen/arch/x86/pv/dom0_build.c | 6 +- xen/arch/x86/pv/domain.c | 30 +- xen/arch/x86/pv/shim.c | 4 +- xen/arch/x86/setup.c | 4 + xen/arch/x86/sparse-directmap.c | 455 ++++++++++++++++++++ xen/arch/x86/spec_ctrl.c | 174 +++++++- xen/arch/x86/x86_64/asm-offsets.c | 1 - xen/arch/x86/x86_64/mm.c | 14 +- xen/common/Kconfig | 18 + xen/common/page_alloc.c | 51 ++- xen/common/xmalloc_tlsf.c | 12 +- xen/include/xen/mm.h | 40 ++ 34 files changed, 1993 insertions(+), 349 deletions(-) create mode 100644 xen/arch/x86/include/asm/sparse-directmap.h create mode 100644 xen/arch/x86/sparse-directmap.c base-commit: 7e020a4dd6ed30eb6c91a9abe2767034e2bb270a -- 2.55.0
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |