On 3/3/2023 5:00 PM, Robert Hoo wrote:
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?
Not the vm-exit handling code. em_invpg() belongs to instruction emulation.
But I am not sure this code is reachable or not. Let me double check.
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.
OK.
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.
