Excerpts from Nicholas Piggin's message of June 14, 2021 10:58 am: > Excerpts from akpm@xxxxxxxxxxxxxxxxxxxx's message of June 9, 2021 7:06 am: >> >> The patch titled >> Subject: KVM: s390: fix for hugepage vmalloc >> has been added to the -mm tree. Its filename is >> kvm-s390-fix-for-hugepage-vmalloc.patch >> >> This patch should soon appear at >> https://ozlabs.org/~akpm/mmots/broken-out/kvm-s390-fix-for-hugepage-vmalloc.patch >> and later at >> https://ozlabs.org/~akpm/mmotm/broken-out/kvm-s390-fix-for-hugepage-vmalloc.patch >> >> Before you just go and hit "reply", please: >> a) Consider who else should be cc'ed >> b) Prefer to cc a suitable mailing list as well >> c) Ideally: find the original patch on the mailing list and do a >> reply-to-all to that, adding suitable additional cc's >> >> *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** >> >> The -mm tree is included into linux-next and is updated >> there every 3-4 working days >> >> ------------------------------------------------------ >> From: Claudio Imbrenda <imbrenda@xxxxxxxxxxxxx> >> Subject: KVM: s390: fix for hugepage vmalloc >> >> The Create Secure Configuration Ultravisor Call does not support using >> large pages for the virtual memory area. This is a hardware limitation. >> >> This patch replaces the vzalloc call with a longer but equivalent >> __vmalloc_node_range call, also setting the VM_NO_HUGE_VMAP flag, to >> guarantee that this allocation will not be performed with large pages. >> >> Link: https://lkml.kernel.org/r/20210608180618.477766-3-imbrenda@xxxxxxxxxxxxx >> Signed-off-by: Claudio Imbrenda <imbrenda@xxxxxxxxxxxxx> >> Reviewed-by: Janosch Frank <frankja@xxxxxxxxxxxxx> >> Fixes: 121e6f3258fe393e22c3 ("mm/vmalloc: hugepage vmalloc mappings") > > Hmm, s390 does not select HAVE_ARCH_HUGE_VMALLOC so it was intended that > "mm/vmalloc: hugepage vmalloc mappings" does not introduce huge vmallocs > for you. > > I can't see how this would happen, any clue what I'm missing? Ah, read into the mailing list thread for the other patch and it seems it only becomes a problem if/when you do enable it, is that right? >From the changelog it appears that this fixes a bug introduced by that patch. I think instead it should go with the series that enables the option, and without the fixes tag. Or if you wanted to get this core API change in first and need a caller in-tree, explain in the changelog that huge vmalloc enablement is coming later and requires it. The enable patch that comes later could reference this commit to help with backporting, if that's what you are concerned about. Thanks, Nick > > Thanks, > Nick > >> Acked-by: Christian Borntraeger <borntraeger@xxxxxxxxxx> [s390] >> Cc: Nicholas Piggin <npiggin@xxxxxxxxx> >> Cc: Uladzislau Rezki (Sony) <urezki@xxxxxxxxx> >> Cc: Catalin Marinas <catalin.marinas@xxxxxxx> >> Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx> >> Cc: Ingo Molnar <mingo@xxxxxxxxxx> >> Cc: David Rientjes <rientjes@xxxxxxxxxx> >> Cc: Janosch Frank <frankja@xxxxxxxxxxxxx> >> Cc: David Hildenbrand <david@xxxxxxxxxx> >> Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> >> --- >> >> arch/s390/kvm/pv.c | 5 ++++- >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> --- a/arch/s390/kvm/pv.c~kvm-s390-fix-for-hugepage-vmalloc >> +++ a/arch/s390/kvm/pv.c >> @@ -140,7 +140,10 @@ static int kvm_s390_pv_alloc_vm(struct k >> /* Allocate variable storage */ >> vlen = ALIGN(virt * ((npages * PAGE_SIZE) / HPAGE_SIZE), PAGE_SIZE); >> vlen += uv_info.guest_virt_base_stor_len; >> - kvm->arch.pv.stor_var = vzalloc(vlen); >> + kvm->arch.pv.stor_var = __vmalloc_node_range(vlen, PAGE_SIZE, VMALLOC_START, VMALLOC_END, >> + GFP_KERNEL | __GFP_ZERO, PAGE_KERNEL, >> + VM_NO_HUGE_VMAP, NUMA_NO_NODE, >> + __builtin_return_address(0)); >> if (!kvm->arch.pv.stor_var) >> goto out_err; >> return 0; >> _ >> >> Patches currently in -mm which might be from imbrenda@xxxxxxxxxxxxx are >> >> mm-vmalloc-export-__vmalloc_node_range.patch >> kvm-s390-fix-for-hugepage-vmalloc.patch >> >> >
