On Wed, Apr 06, 2022 at 10:34:41PM -0500, Richard Henderson wrote: > On 4/6/22 20:01, Kirill A. Shutemov wrote: > > Linear Address Masking feature makes CPU ignore some bits of the virtual > > address. These bits can be used to encode metadata. > > > > The feature is enumerated with CPUID.(EAX=07H, ECX=01H):EAX.LAM[bit 26]. > > > > CR3.LAM_U57[bit 62] allows to encode 6 bits of metadata in bits 62:57 of > > user pointers. > > > > CR3.LAM_U48[bit 61] allows to encode 15 bits of metadata in bits 62:48 > > of user pointers. > > > > CR4.LAM_SUP[bit 28] allows to encode metadata of supervisor pointers. > > If 5-level paging is in use, 6 bits of metadata can be encoded in 62:57. > > For 4-level paging, 15 bits of metadata can be encoded in bits 62:48. > > > > QEMU strips address from the metadata bits and gets it to canonical > > shape before handling memory access. It has to be done very early before > > TLB lookup. > > The new hook is incorrect, in that it doesn't apply to addresses along > the tlb fast path.
I'm not sure what you mean by that. tlb_hit() mechanics works. We strip the tag bits before tlb lookup. Could you elaborate? > But it isn't really needed. You can do all of the work in the existing > tlb_fill hook. AArch64 has a similar feature, and that works fine. To be honest I don't fully understand how TBI emulation works. Consider store_helper(). I failed to find where tag bits get stripped before getting there for !CONFIG_USER_ONLY. clean_data_tbi() only covers user-only case. And if we get there with tags, I don't see how we will ever get to fast path: tlb_hit() should never return true there if any bit in top byte is set as cached tlb_addr has them stripped. tlb_fill() will get it handled correctly, but it is wasteful to go through pagewalk on every tagged pointer dereference. Hm? -- Kirill A. Shutemov
