> On 16 Jul 2019, at 22:45, Sean Christopherson <sean.j.christopherson@xxxxxxxxx> wrote: > > On Tue, Jul 16, 2019 at 09:39:48PM +0200, Paolo Bonzini wrote: >> On 16/07/19 21:34, Liran Alon wrote: >>>> When this errata is hit, the CPU will be at CPL3. From hardware >>>> point-of-view the below sequence happens: >>>> >>>> 1. CPL3 guest hits reserved bit NPT fault (MMIO access) >>> Why CPU needs to be at CPL3? >>> The requirement for SMAP should be that this page is user-accessible in guest page-tables. >>> Think on a case where guest have CR4.SMAP=1 and CR4.SMEP=0. >>> >> >> If you are not at CPL3, you'd get a SMAP NPF, not a RSVD NPF. > > I think Liran is right. When software is executing, the %rip access is > a code fetch (SMEP), but the ucode assist is a data access (SMAP). > > This likely has only been observed in a CPL3 scenario because no sane OS > exercises the case of the kernel executing from a user page with SMAP=1 > and SMEP=0. True. I’m trying to be pedantic and accurate here. :) I think we should just remove the vCPU CPL check and remain only with the CR4.SMAP check. Don’t you agree that having a #NPF that returns 0 instruction bytes with DecodeAssist enabled and CR4.SMAP=1 is sufficient for finger-printing this Errata? With which other use-case it’s expected to collide? -Liran
