On Fri, 2023-03-03 at 11:35 +0800, Binbin Wu wrote: > > > > > Also the instruction INVLPG, INVPCID should have some special > > > > > handling > > > > > since LAM is not applied to the memory operand of the two > > > > > instruction > > > > > according to the LAM spec. > > > > > > > > The spec's meaning on these 2 is: LAM masking doesn't apply to > > > > their > > > > operands (the address), so the behavior is like before LAM > > > > feature > > > > introduced. No change. > > > > > > Yes, LAM are not applied to the 2 instrustions, but the > > > __linearize > > > is > > > changed. > > > For example, the emulation of invlpg (em_invpg) will also call > > > it. Can you elaborate more on this? what emulation case of INVLPG? do you mean vm-exit handling due to Guest execute INVLPG when VMCS_control.INVLPG_exiting set? or other case? > > > So > > > need to handle the case specificlly. > > > Can add a flag as the input of linearize to indicate the LAM > > > check > > > and > > > untag is needed or not. > > > > > > > No need. > > > > "The INVLPG instruction ... > > LAM does not apply to the specified memory address. Thus, in 64-bit > > mode, ** if the memory address specified is in non-canonical form > > then > > the INVLPG is the same as a NOP. ** > > Based on current patch, if the address of invlpg is non-canonical, > it > will be first checked and converted by the new LAM handling. > After that, I will be canonical and do the invalidition, but not NOP. > Maybe we can say do an additional TLB invalidation may be no big > different as NOP, but it need to be documented/comment somewhere > > > > > > The INVPCID instruction ... > > LAM does not apply to the specified memory address, and in 64-bit > > mode ** if this memory address is in non-canonical form then the > > processor generates a #GP(0) exception. **" > > > > You can double confirm in SDM: Before-and-After LAM introduced, the > > behavior hasn't changed. Thus you don't need to worry about these 2 > > INS's emulations. > > This is because currently, VMX vmexit handling is not considered yet. > The linear address of guest is retrived from get_vmx_mem_address, > which > is also will be called by INVPCID. Again, nested LAM isn't in this patch set's scope. In terms of handle_invpcid() --> get_vmx_mem_address(), per Spec, no behavior changes, no changes needed. > > What arguable is that we need to cover all supervisor mode pointer > cases > in this phase. > But IMO if thesel cases are not covered, CR4.LAM_SUP should be not > allow > to be set by guest. >
