architecture: 0.944
graphic: 0.932
debug: 0.918
mistranslation: 0.910
performance: 0.893
kernel: 0.870
semantic: 0.846
arm: 0.815
ppc: 0.810
device: 0.780
network: 0.774
user-level: 0.764
register: 0.759
i386: 0.752
vnc: 0.737
hypervisor: 0.734
PID: 0.733
peripherals: 0.715
risc-v: 0.709
VMM: 0.708
permissions: 0.700
assembly: 0.697
files: 0.684
x86: 0.679
TCG: 0.671
socket: 0.623
virtual: 0.559
boot: 0.470
KVM: 0.427

aarch64 tlb range invalidate is not accurate
Description of problem:
In this (https://gitlab.com/qemu-project/qemu/-/commit/84940ed82552d3c7c7327c83076b02cee7978257) commit, tlb range invalidate support is added, and I think qemu's range calculation is wrong.

In `tlbi_aa64_range_get_length` function, `num`, `scale`, `page_size_granule` is caculated as below.


```
    num = extract64(value, 39, 4);
    scale = extract64(value, 44, 2);
    page_size_granule = extract64(value, 46, 2);

    page_shift = page_size_granule * 2 + 12;
```

As [Arm documentation](https://developer.arm.com/documentation/ddi0595/2021-06/AArch64-Instructions/TLBI-RVALE1--TLBI-RVALE1NXS--TLB-Range-Invalidate-by-VA--Last-level--EL1), NUM bits's length is 5, but the code above only extract 4bits.

And `page_shift` also should be calculated as `(page_size_granule-1) <<1) + 12` rather than `page_size_granule * 2 + 12`.
Steps to reproduce:
1.
2.
3.
Additional information:
I found this issue while debugging a phenomenon that kernel panic occurs randomly in my qemu fork.

I'm pretty sure this is one of the causes, but even if I roughly correct it, my problem has not been solved.

I think my problem is TLB invalidate related issue, so if I find any more problems, I'll comment here.