On Mon, Apr 29, 2019 at 3:08 PM Sean Christopherson sean.j.christopherson@intel.com wrote:
FWIW, Lakemont (Quark) doesn't block NMI/SMI in the STI shadow, but I'm not sure that counters the "horrible errata" statement ;-). SMI+RSM saves and restores STI blocking in that case, but AFAICT NMI has no such protection and will effectively break the shadow on its IRET.
Ugh. I can't say I care deeply about Quark (ie never seemed to go anywhere), but it's odd. I thought it was based on a Pentium core (or i486+?). Are you saying those didn't do it either?
I have this dim memory about talking about this with some (AMD?) engineer, and having an alternative approach for the sti shadow wrt NMI - basically not checking interrupts in the instruction you return to with 'iret'. I don't think it was even conditional on the "iret from NMI", I think it was basically any iret also did the sti shadow thing.
But I can find no actual paper to back that up, so this may be me just making sh*t up.
KVM is generally ok with respect to STI blocking, but ancient versions didn't migrate STI blocking and there's currently a hole where single-stepping a guest (from host userspace) could drop STI_BLOCKING if a different VM-Exit occurs between the single-step #DB VM-Exit and the instruction in the shadow. Though "don't do that" may be a reasonable answer in that case.
I thought the sti shadow blocked the single-step exception too? I know "mov->ss" does block debug interrupts too.
Or are you saying that it's some "single step by emulation" that just miss setting the STI_BLOCKING flag?
Linus