Re: [RFC PATCH] KVM: x86: Dynamically allocate bitmap to fix -Wframe-larger-than error

[Sean Christopherson <seanjc@google.com>]

On Fri, Jun 13, 2025, avinashlalotra wrote:
> Building the kernel with LLVM fails due to
> a stack frame size overflow in `kvm_hv_flush_tlb()`:
> 
>     arch/x86/kvm/hyperv.c:2001:12: error: stack frame size (1336) exceeds limit (1024) in 'kvm_hv_flush_tlb' [-Werror,-Wframe-larger-than]
> 
> The issue is caused by a large bitmap allocated on the stack. To resolve
> this, dynamically allocate the bitmap using `bitmap_zalloc()` and free it with
> `bitmap_free()` after use. This reduces the function's stack usage and avoids
> the compiler error when `-Werror` is set.

Can you provide your full .config?  It's not at all difficult to get this function
(and others) to exceed the frame size with various sanitizers and/or deubg options
enabled, which is why KVM_WERROR depends on EXPERT=y or KASAN=n.

  config KVM_WERROR
	bool "Compile KVM with -Werror"
	# Disallow KVM's -Werror if KASAN is enabled, e.g. to guard against
	# randomized configs from selecting KVM_WERROR=y, which doesn't play
	# nice with KASAN.  KASAN builds generates warnings for the default
	# FRAME_WARN, i.e. KVM_WERROR=y with KASAN=y requires special tuning.
	# Building KVM with -Werror and KASAN is still doable via enabling
	# the kernel-wide WERROR=y.
	depends on KVM && ((EXPERT && !KASAN) || WERROR)

And also why kernel/configs/debug.config bumps the size to 2048.

	CONFIG_FRAME_WARN=2048

> Please provide me feedback about this patch . There were more warnings like
> that, So If this is the correct way to fic such issues then I will submit
> patches for them.

As above, this may just be a "bad" .config.