On Fri, 2023-03-03 at 09:08 +0800, Binbin Wu wrote: > On 3/2/2023 9:16 PM, Robert Hoo wrote: > > On Thu, 2023-03-02 at 14:41 +0800, Binbin Wu wrote: > > > __linearize is not the only path the modified LAM canonical check > > > needed, also some vmexits path should be taken care of, like VMX, > > > SGX > > > ENCLS. > > > > > > > SGX isn't in this version's implementation's scope, like nested > > LAM. > > LAM in SGX enclave mode is not the scope of the this version. > But I think since the capability is exposed to guest, I think you can document this or other method to call out this to user. Even Kernel enabling doesn't include SGX interaction yet, I doubt if it's that urgent for KVM to do this at this phase. > need to cover the > case if the guest use the supervisor mode pointer No business with pointer mode here, I think. > as the operand of SGX > EENCS operations. > > > > > > > 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. > 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. ** 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.
