8897ea5a9f
The Real Mode Area (RMA) is the part of memory which a guest can access when in real (MMU off) mode. Of course, for a guest under KVM, the MMU isn't really turned off, it's just in a special translation mode - Virtual Real Mode Area (VRMA) - which looks like real mode in guest mode. The mechanics of how this works when using the hash MMU (HPT) put a constraint on the size of the RMA, which depends on the size of the HPT. So, the latter part of spapr_setup_hpt_and_vrma() clamps the RMA we advertise to the guest based on this VRMA limit. There are several things wrong with this: 1) spapr_setup_hpt_and_vrma() doesn't actually clamp, it takes the minimum of Node 0 memory size and the VRMA limit. That will *often* work the same as clamping, but there can be other constraints on RMA size which supersede Node 0 memory size. We have real bugs caused by this (currently worked around in the guest kernel) 2) Some callers of spapr_setup_hpt_and_vrma() are in a situation where we're past the point that we can actually advertise an RMA limit to the guest 3) But most fundamentally, the VRMA limit depends on host configuration (page size) which shouldn't be visible to the guest, but this partially exposes it. This can cause problems with migration in certain edge cases, although we will mostly get away with it. In practice, this clamping is almost never applied anyway. With 64kiB pages and the normal rules for sizing of the HPT, the theoretical VRMA limit will be 4x(guest memory size) and so never hit. It will hit with 4kiB pages, where it will be (guest memory size)/4. However all mainstream distro kernels for POWER have used a 64kiB page size for at least 10 years. So, simply replace this logic with a check that the RMA we've calculated based only on guest visible configuration will fit within the host implied VRMA limit. This can break if running HPT guests on a host kernel with 4kiB page size. As noted that's very rare. There also exist several possible workarounds: * Change the host kernel to use 64kiB pages * Use radix MMU (RPT) guests instead of HPT * Use 64kiB hugepages on the host to back guest memory * Increase the guest memory size so that the RMA hits one of the fixed limits before the RMA limit. This is relatively easy on POWER8 which has a 16GiB limit, harder on POWER9 which has a 1TiB limit. * Use a guest NUMA configuration which artificially constrains the RMA within the VRMA limit (the RMA must always fit within Node 0). Previously, on KVM, we also temporarily reduced the rma_size to 256M so that the we'd load the kernel and initrd safely, regardless of the VRMA limit. This was a) confusing, b) could significantly limit the size of images we could load and c) introduced a behavioural difference between KVM and TCG. So we remove that as well. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: Greg Kurz <groug@kaod.org> |
||
---|---|---|
.. | ||
e500-ccsr.h | ||
e500.c | ||
e500.h | ||
e500plat.c | ||
fdt.c | ||
fw_cfg.c | ||
Kconfig | ||
mac_newworld.c | ||
mac_oldworld.c | ||
mac.h | ||
Makefile.objs | ||
mpc8544_guts.c | ||
mpc8544ds.c | ||
pnv_bmc.c | ||
pnv_core.c | ||
pnv_homer.c | ||
pnv_lpc.c | ||
pnv_occ.c | ||
pnv_pnor.c | ||
pnv_psi.c | ||
pnv_xscom.c | ||
pnv.c | ||
ppc4xx_devs.c | ||
ppc4xx_pci.c | ||
ppc405_boards.c | ||
ppc405_uc.c | ||
ppc405.h | ||
ppc440_bamboo.c | ||
ppc440_pcix.c | ||
ppc440_uc.c | ||
ppc440.h | ||
ppc_booke.c | ||
ppc.c | ||
ppce500_spin.c | ||
prep_systemio.c | ||
prep.c | ||
rs6000_mc.c | ||
sam460ex.c | ||
spapr_caps.c | ||
spapr_cpu_core.c | ||
spapr_drc.c | ||
spapr_events.c | ||
spapr_hcall.c | ||
spapr_iommu.c | ||
spapr_irq.c | ||
spapr_nvdimm.c | ||
spapr_ovec.c | ||
spapr_pci_nvlink2.c | ||
spapr_pci_vfio.c | ||
spapr_pci.c | ||
spapr_rng.c | ||
spapr_rtas_ddw.c | ||
spapr_rtas.c | ||
spapr_rtc.c | ||
spapr_tpm_proxy.c | ||
spapr_vio.c | ||
spapr.c | ||
trace-events | ||
virtex_ml507.c |