On 8/4/2023 12:37 AM, Peter Zijlstra wrote: > On Thu, Aug 03, 2023 at 08:06:20PM +0200, Paolo Bonzini wrote: >> On 8/3/23 14:06, Peter Zijlstra wrote: >>> >>> By marking them with STACK_FRAME_NON_STANDARD you will get no ORC data >>> at all, and then you also violate the normal framepointer calling >>> convention. >>> >>> This means that if you need to unwind here you're up a creek without no >>> paddles on. >> >> The only weird thing that can happen is ud2 instructions that are executed >> in case the vmload/vmrun/vmsave instructions causes a #GP, from the >> exception handler. > > This code is ran with GIF disabled, so NMIs are not in the books, right? > Does GIF block #MC ? > >> If I understand correctly those ud2 would use ORC information to show the >> backtrace, but even then the frame pointer should be correct. Of these >> instructions, vmrun is the only one that runs with wrong %rbp; and it is >> unlikely or even impossible that a #GP happens at vmrun, because the same >> operand has been used for a vmload ten instructions before. The only time I >> saw that #GP it was due to a processor errata, but it happened consistently >> on the vmload. >> >> So if frame pointer unwinding can be used in the absence of ORC, Nikunj >> patch should not break anything. > > But framepointer unwinds rely on BP, and that is clobbered per the > objtool complaint. > > Also, if you look at the makefile hunk that's being replaced, that was > conditional on CONFIG_FRAMEPOINTS, while the annotation that's being > added is not. Even with the hunk present with CONFIG_FRAME_POINTER=y, I was getting the warning. That is why I had added the STACK_FRAME_NON_STANDARD and removed the hunk in makefile. Do you recommend using the below instead ? #ifdef CONFIG_FRAME_POINTER STACK_FRAME_NON_STANDARD() #endif Regards Nikunj
