Re: [PATCH v5 4/5] KVM: x86: emulation: Apply LAM mask when emulating data access in 64-bit mode

[Binbin Wu <binbin.wu@linux.intel.com>]

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.
>>