[OLK-6.6] Backport upstream merged "c0900d15d31c arm64: Ensure bits ASID[15:8] are masked out when the kernel uses 8-bit ASIDs"

> _**请尽量提供详细的信息，如缺乏必要的定位信息，则缺陷不会被定位**_ ## 环境信息 【OS版本】（如openEuler-22.03-LTS，参考命令"cat /etc/os-release"结果） 【内核版本】（如kernel-5.10.0-60.138.0.165，参考命令"uname -r"结果） kernel OLK-6.6 lastest 【硬件平台】（缺陷相关的硬件信息，如：处理器型号、内存、磁盘、网卡、BIOS 等信息） ARM64 【组网信息】（和网络、性能相关的问题，应该说明详细的组网和场景信息） ## 缺陷信息 ``` Linux currently sets the TCR_EL1.AS bit unconditionally during CPU bring-up. On an 8-bit ASID CPU, this is RES0 and ignored, otherwise 16-bit ASIDs are enabled. However, if running in a VM and the hypervisor reports 8-bit ASIDs (ID_AA64MMFR0_EL1.ASIDBits == 0) on a 16-bit ASIDs CPU, Linux uses bits 8 to 63 as a generation number for tracking old process ASIDs. The bottom 8 bits of this generation end up being written to TTBR1_EL1 and also used for the ASID-based TLBI operations as the upper 8 bits of the ASID. Following an ASID roll-over event we can have threads of the same application with the same 8-bit ASID but different generation numbers running on separate CPUs. Both TLB caching and the TLBI operations will end up using different actual 16-bit ASIDs for the same process. A similar scenario can happen in a big.LITTLE configuration if the boot CPU only uses 8-bit ASIDs while secondary CPUs have 16-bit ASIDs. Ensure that the ASID generation is only tracked by bits 16 and up, leaving bits 15:8 as 0 if the kernel uses 8-bit ASIDs. Note that clearing TCR_EL1.AS is not sufficient since the architecture requires that the top 8 bits of the ASID passed to TLBI instructions are 0 rather than ignored in such configuration. ``` 【问题复现步骤】 1. 2. 3. 【实际结果】请描述出问题的结果和影响 Both TLB caching and the TLBI operations will end up using different actual 16-bit ASIDs for the same process. 【期望结果】请描述出期望的结果和影响 Fix the case 【其他相关附件信息】比如 syslog、dmesg、panic、lockup、kdump 信息、图片等 ``` # 这里可以附上相关文本信息 ``` 【已分析信息】如已经做过分析和定位，请尽量附上详细的分析结果