On Fri, Nov 11, 2022 at 01:29:35AM -0800, H. Peter Anvin wrote: > On November 11, 2022 1:19:23 AM PST, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > >On Thu, Nov 10, 2022 at 08:53:09PM +0000, Sean Christopherson wrote: > >> On Thu, Nov 10, 2022, Li, Xin3 wrote: > > > >> > > > + * call thus the values in the pt_regs structure are not used in > >> > > > + * executing NMI/IRQ handlers, > >> > > > >> > > Won't this break stack traces to some extent? > >> > > > >> > > >> > The pt_regs structure, and its IP/CS, is NOT part of the call stack, thus > >> > I don't see a problem. No? > > > >I'm not sure what Xin3 is trying to say, but NMI/IRQ handers use pt_regs > >a *LOT*. pt_regs *MUST* be correct. > > What is "correct" in this context? I don't know since I don't really speak virt, but I could image the regset that would match the vmrun (or whatever intel decided to call that again) instruction. > Could you describe what aspects of > the register image you rely on, and what you expect them to be? We rely on CS,IP,FLAGS,SS,SP to be coherent and usable at the very least (must be able to start an unwind from it). But things like perf (NMI) access *all* of them and possibly copy them out to userspace. Perf can also try and use the segment registers in order to try and establish a linear address. Some exceptions (#GP) access whatever is needed to fully decode and emulate the instruction (IOPL,UMIP,etc..) including the segment registers. > Currently KVM basically stuff random data into pt_regs; this at least > makes it explicitly zero. :-( Both is broken. Once again proving to me that virt is a bunch of duck-tape at best.
