On 3/3/2023 11:16 AM, Robert Hoo wrote:
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. **
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.
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.
