mbox series

[5.15.y,0/2] fix softlockups in stage2_apply_range()

Message ID cover.1709665227.git.kjlx@templeofstupid.com (mailing list archive)
Headers show
Series fix softlockups in stage2_apply_range() | expand

Message

Krister Johansen March 5, 2024, 7:41 p.m. UTC
Hi Stable Team,
In 5.15, unmapping large kvm vms on arm64 can generate softlockups.  My team has
been hitting this when tearing down VMs > 100Gb in size.

Oliver fixed this with the attached patches.  They've been in mainline since
6.1.

I tested on 5.15.150 with these patches applied. When they're present,
both the dirty_log_perf_test detailed in the second patch, and
kvm_page_table_test no longer generate softlockups when unmapping VMs
with large memory configurations.

Would you please consider these patches for inclusion in an upcoming 5.15
release?

Thanks,

-K

Oliver Upton (2):
  KVM: arm64: Work out supported block level at compile time
  KVM: arm64: Limit stage2_apply_range() batch size to largest block

 arch/arm64/include/asm/kvm_pgtable.h    | 18 +++++++++++++-----
 arch/arm64/include/asm/stage2_pgtable.h | 20 --------------------
 arch/arm64/kvm/mmu.c                    |  9 ++++++++-
 3 files changed, 21 insertions(+), 26 deletions(-)

Comments

Oliver Upton March 5, 2024, 7:49 p.m. UTC | #1
On Tue, Mar 05, 2024 at 11:41:38AM -0800, Krister Johansen wrote:
> Hi Stable Team,
> In 5.15, unmapping large kvm vms on arm64 can generate softlockups.  My team has
> been hitting this when tearing down VMs > 100Gb in size.
> 
> Oliver fixed this with the attached patches.  They've been in mainline since
> 6.1.
> 
> I tested on 5.15.150 with these patches applied. When they're present,
> both the dirty_log_perf_test detailed in the second patch, and
> kvm_page_table_test no longer generate softlockups when unmapping VMs
> with large memory configurations.
> 
> Would you please consider these patches for inclusion in an upcoming 5.15
> release?

Backport looks fine, and I have no issues with this going to stable if
it helps folks.

Acked-by: Oliver Upton <oliver.upton@linux.dev>