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@xxxxxxxxx> 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 :-)
