CVE-2024-35980: arm64: tlb: Fix TLBI RANGE operand

In the Linux kernel, the following vulnerability has been resolved:

arm64: tlb: Fix TLBI RANGE operand

KVM/arm64 relies on TLBI RANGE feature to flush TLBs when the dirty pages are collected by VMM and the page table entries become write protected during live migration. Unfortunately, the operand passed to the TLBI RANGE instruction isn't correctly sorted out due to the commit 117940aa6e5f ("KVM: arm64: Define kvmtlbflushvmidrange()"). It leads to crash on the destination VM after live migration because TLBs aren't flushed completely and some of the dirty pages are missed.

For example, I have a VM where 8GB memory is assigned, starting from 0x40000000 (1GB). Note that the host has 4KB as the base page size. In the middile of migration, kvmtlbflushvmidrange() is executed to flush TLBs. It passes MAXTLBIRANGEPAGES as the argument to kvmtlbflushvmidrange() and flushs2tlbrangeop(). SCALE#3 and NUM#31, corresponding to MAXTLBIRANGEPAGES, isn't supported by TLBIRANGENUM(). In this specific case, -1 has been returned from TLBIRANGENUM() for SCALE#3/2/1/0 and rejected by the loop in the flushtlbrangeop() until the variable @scale underflows and becomes -9, 0xffff708000040000 is set as the operand. The operand is wrong since it's sorted out by TLBIVADDRRANGE() according to invalid @scale and @num.

Fix it by extending TLBIRANGENUM() to support the combination of SCALE#3 and NUM#31. With the changes, [-1 31] instead of [-1 30] can be returned from the macro, meaning the TLBs for 0x200000 pages in the above example can be flushed in one shoot with SCALE#3 and NUM#31. The macro TLBIRANGEMASK is dropped since no one uses it any more. The comments are also adjusted accordingly.