On Mon, May 17, 2021, Jim Mattson wrote: > On Mon, May 17, 2021 at 11:05 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > > > On Mon, May 17, 2021, Dave Hansen wrote: > > > On 5/17/21 10:49 AM, Andy Lutomirski wrote: > > > >> The least awful solution would be to have the NMI handler restore > > > >> the host's PKRU. The NMI handler would need to save/restore the > > > >> register, a la CR2, but the whole thing could be optimized to run > > > >> if and only if the NMI lands in the window where the guest's PKRU > > > >> is loaded. > > > > > > > > Or set a flag causing nmi_uaccess_ok() to return false. > > > > > > Oh, that doesn't sound too bad. The VMENTER/EXIT paths are also > > > essentially a context switch. > > > > I like that idea, too. > > > > The flag might also be useful to fix the issue where the NMI handler activates > > PEBS after KVM disables it. Jim? > > The issue is actually that the NMI handler *clears* IA32_PEBS_ENABLE > bits after giving out the host value of the MSR to KVM. If we were to > block the NMI handler from modifying IA32_PEBS_ENABLE until after the > next VM-exit, that could solve this issue. I don't know if it makes > sense to piggyback on nmi_uaccess(), though. I wasn't thinking about using nmi_uaccess_okay(), but rather whatever flag is added so that can KVM can inform the NMI handler that KVM is in the middle of its version of a context switch. > > > Will widening the window where nmi_uaccess_okay()==false anger any of > > > the perf folks? It looks like perf knows how to handle it nicely.
