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

[Robert Hoo <robert.hu@linux.intel.com>]

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