On Fri, Jul 24, 2020 at 01:26:00PM +0530, Aneesh Kumar K.V wrote: > This adds a kernel command line option that can be used to disable GTSE > support. > Disabling GTSE implies kernel will make hcalls to invalidate TLB entries. > > This was done so that we can do VM migration between configs that > enable/disable > GTSE support via hypervisor. To migrate a VM from a system that supports > GTSE to a system that doesn't, we can boot the guest with radix_gtse=off, > thereby > forcing the guest to use hcalls for TLB invalidates. > > The check for hcall availability is done in pSeries_setup_arch so that > the panic message appears on the console. This should only happen on > a hypervisor that doesn't force the guest to hash translation even > though it can't handle the radix GTSE=0 request via CAS. With radix_gtse=off > if the hypervisor doesn't support hcall_rpt_invalidate hcall it should > force the LPAR to hash translation. > > Signed-off-by: Aneesh Kumar K.V <aneesh.ku...@linux.ibm.com> > --- > Documentation/admin-guide/kernel-parameters.txt | 3 +++ > arch/powerpc/include/asm/firmware.h | 4 +++- > arch/powerpc/kernel/prom_init.c | 13 +++++++++---- > arch/powerpc/platforms/pseries/firmware.c | 1 + > arch/powerpc/platforms/pseries/setup.c | 5 +++++ > 5 files changed, 21 insertions(+), 5 deletions(-) Tested
1. radix_gtse=off with KVM implementation of H_RPT_INVALIDATE hcall, the tlb flush calls get off-loaded to hcalls. 2. radix_gtse=off w/o H_RPT_INVALIDATE hcall, the guest kernel panics as per design. However in both cases, the guest kernel prints out "WARNING: Hypervisor doesn't support RADIX with GTSE" which can be a bit confusing in case 1 as GTSE has disabled by the guest and hypervisor is capable of supporting the same via hcall. Regards, Bharata.