On 2/13/19 12:33 PM, Paolo Bonzini wrote: > 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. > This errata is applicable to Family 17h model 00_0fh only, and it is definitely planned to fix in the upcoming CPUs. For now, we just need to workaround for the Fam 17h_00_0Fh. I am not sure about blacklist SMAP all together, for non SEV its very easy to workaround. For SEV case, I am just trying to say that we will *not* workaround (it does not mean that its not possible) > 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? > Theoretically we should be able to do this to workaround. But since the errata is not wide spread hence I am not sure about going to this path. Also there are not many apps doing MMIO from userspace hence I thought its okay to not workaround for the SEV guest. Having said so, if we find the actual need to workaround then we can go to that path. thanks
