On 2/14/19 6:26 AM, Paolo Bonzini wrote: > On 13/02/19 20:02, Singh, Brijesh wrote: >>> 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. > > So it's on all steppings; no microcode fix. :( Unfortunately yes :( > >> 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. > > If it's not too hard, having the workaround would be nice(r). > For now I am inclined to go with what we have. Will submit v2 with fixes. Theoretically we can use the single stepping with CR4.SMAP=0. Since this is not a suggested workaround in errata doc hence I am afraid that we may run into some unknown (mainly with SEV); I will check with HW folks to get some acknowledgment. If we all feel comfortable then I will submit a follow up patch. thanks -Brijesh
