mirror of
https://mirrors.bfsu.edu.cn/git/linux.git
synced 2024-11-15 08:14:15 +08:00
1156b4418d
With CXL security features, and CXL dynamic provisioning, global CPU cache flushing nvdimm requirements are no longer specific to that subsystem, even beyond the scope of security_ops. CXL will need such semantics for features not necessarily limited to persistent memory. The functionality this is enabling is to be able to instantaneously secure erase potentially terabytes of memory at once and the kernel needs to be sure that none of the data from before the erase is still present in the cache. It is also used when unlocking a memory device where speculative reads and firmware accesses could have cached poison from before the device was unlocked. Lastly this facility is used when mapping new devices, or new capacity into an established physical address range. I.e. when the driver switches DeviceA mapping AddressX to DeviceB mapping AddressX then any cached data from DeviceA:AddressX needs to be invalidated. This capability is typically only used once per-boot (for unlock), or once per bare metal provisioning event (secure erase), like when handing off the system to another tenant or decommissioning a device. It may also be used for dynamic CXL region provisioning. Users must first call cpu_cache_has_invalidate_memregion() to know whether this functionality is available on the architecture. On x86 this respects the constraints of when wbinvd() is tolerable. It is already the case that wbinvd() is problematic to allow in VMs due its global performance impact and KVM, for example, has been known to just trap and ignore the call. With confidential computing guest execution of wbinvd() may even trigger an exception. Given guests should not be messing with the bare metal address map via CXL configuration changes cpu_cache_has_invalidate_memregion() returns false in VMs. While this global cache invalidation facility, is exported to modules, since NVDIMM and CXL support can be built as a module, it is not for general use. The intent is that this facility is not available outside of specific "device-memory" use cases. To make that expectation as clear as possible the API is scoped to a new "DEVMEM" module namespace that only the NVDIMM and CXL subsystems are expected to import. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: x86@kernel.org Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Tested-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Davidlohr Bueso <dave@stgolabs.net> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Co-developed-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> |
||
|---|---|---|
| .. | ||
| pat | ||
| amdtopology.c | ||
| cpu_entry_area.c | ||
| debug_pagetables.c | ||
| dump_pagetables.c | ||
| extable.c | ||
| fault.c | ||
| highmem_32.c | ||
| hugetlbpage.c | ||
| ident_map.c | ||
| init_32.c | ||
| init_64.c | ||
| init.c | ||
| iomap_32.c | ||
| ioremap.c | ||
| kasan_init_64.c | ||
| kaslr.c | ||
| kmmio.c | ||
| kmsan_shadow.c | ||
| maccess.c | ||
| Makefile | ||
| mem_encrypt_amd.c | ||
| mem_encrypt_boot.S | ||
| mem_encrypt_identity.c | ||
| mem_encrypt.c | ||
| mm_internal.h | ||
| mmap.c | ||
| mmio-mod.c | ||
| numa_32.c | ||
| numa_64.c | ||
| numa_emulation.c | ||
| numa_internal.h | ||
| numa.c | ||
| pf_in.c | ||
| pf_in.h | ||
| pgprot.c | ||
| pgtable_32.c | ||
| pgtable.c | ||
| physaddr.c | ||
| physaddr.h | ||
| pkeys.c | ||
| pti.c | ||
| srat.c | ||
| testmmiotrace.c | ||
| tlb.c | ||