On 13/02/19 19:28, Singh, Brijesh wrote: > > > On 2/13/19 11:23 AM, Paolo Bonzini wrote: >> On 13/02/19 18:19, Singh, Brijesh wrote: >>> 1. Guest does the MMIO access which causes a rsvd page fault >>> 2. Hardware processes this as a VMEXIT >>> 3. During the processing, hardware attempts to read the instruction >>> bytes. This is done by issuing a data read request from the RIP >>> that the guest was at. >>> 4. The result of these reads are then stored in the VMCB. >>> >>> So in step #3 there can be a SMAP fault because internally the CPU >>> is doing a data read from the RIP to get these bytes. Hardware didn't >>> save them from the actual instruction execution or anything, it >>> actually go and re-read them, which is why this can cause a SMAP >>> fault. >> >> What combination of NPF bits, EFLAGS and CR4 is causing a SMAP fault? > > e.g > > 1. Guest has SMAP enabled > 2. RIP is mapped in guest page tables with U/S=1 Ok so that's pretty messed up. Is this fixed with newer microcode, and how widespread is this silicon? I'm tempted to just blacklist SMAP on the affected steppings. Would it work to retry the instruction with CR4.SMAP=0 and EFLAGS.TF=1, and set CR4.SMAP back to 1 in the #DB handler? Thanks, Paolo > The CPU always does the these insn reads as if CPL=0. In the above case > the insn fetch #3 will cause SMAP fault in the hardware. On VMEXIT, > KVM will get the #NPF with a RSVD fault. > >> Does KVM actually use that combination? > > Sorry, I am not sure if I understand you question. From KVM point-of- > view, we get a #NPF (a RSVD fault). > > I have not encountered this in any of my guest runs (typically > we don't do MMIO at CPL=3). > > -Brijesh >
