Re: [PATCH 1/2] KVM: SVM: Fix workaround for AMD Errata 1096

[Sean Christopherson <sean.j.christopherson@intel.com>]

On Tue, Jul 16, 2019 at 07:56:31PM +0300, Liran Alon wrote:
> 
> > On 16 Jul 2019, at 19:41, Sean Christopherson <sean.j.christopherson@intel.com> wrote:
> > 
> > On Tue, Jul 16, 2019 at 07:20:42PM +0300, Liran Alon wrote:
> >> How can a SMAP fault occur when CPL==3? One of the conditions for SMAP is
> >> that CPL<3.
> > 
> > The CPU is effectively at CPL0 when it does the decode assist, e.g.:
> > 
> >  1. CPL3 guest hits reserved bit NPT fault (MMIO access)
> >  2. CPU transitions to CPL0 on VM-Exit
> >  3. CPU performs data access on **%rip**, encounters SMAP violation
> >  4. CPU squashes SMAP violation, sets VMCB.insn_len=0
> >  5. CPU delivers VM-Exit to software for original NPT fault
> > 
> > The original NPT fault is due to a reserved bit (or not present) entry for
> > a MMIO GPA, *not* the GPA corresponding to %rip.  The fault on the decode
> > assist is never delivered to software, it simply results in having invalid
> > info in the VMCB's insn_bytes and insn_len fields.
> 
> If the CPU performs the VMExit transition of state before doing the data read
> for DecodeAssist, then I agree that CPL will be 0 on data-access regardless
> of vCPU CPL. But this also means that SMAP violation should be raised based
> on host CR4.SMAP value and not vCPU CR4.SMAP value as KVM code checks.
> Furthermore, vCPU CPL of guest doesn’t need to be 3 in order to trigger this
> Errata.

Doh, #2 above is likely wrong.  My *guess* is that the DecodeAssist walk
starts with %rip, i.e. does a NPT walk using the guest context, and that
the access is always an implicit system (CPL0) access.

I'll get out of the way and let Brijesh answer :-)