On Mon, 2022-10-24 at 16:10 +0000, Sean Christopherson wrote: > On Mon, Oct 24, 2022, Maxim Levitsky wrote: > > On Thu, 2022-10-20 at 19:14 +0000, Sean Christopherson wrote: > > > On Thu, Oct 20, 2022, Maxim Levitsky wrote: > > > > + // ensure that a pending timer is serviced > > > > + irq_enable(); > > > > > > Jumping back to the "nop" patch, I'm reinforcing my vote to add sti_nop(). I > > > actually starting typing a response to say this is broken before remembering that > > > a nop got added to irq_enable(). > > > > OK, although, for someone that doesn't know about the interrupt shadow (I > > guess most of the people that will look at this code), the above won't > > confuse them, in fact sti_nop() might confuse someone who doesn't know about > > why this nop is needed. > > The difference is that sti_nop() might leave unfamiliar readers asking "why", but > it won't actively mislead them. And the "why" can be easily answered by a comment > above sti_nop() to describe its purpose. A "see also safe_halt()" with a comment > there would be extra helpful, as "safe halt" is the main reason the STI shadow is > even a thing. > > On the other hand, shoving a NOP into irq_enable() is pretty much guaranteed to > cause problems for readers that do know about STI shadows since there's nothing > in the name "irq_enable" that suggests that the helper also intentionally eats the > interrupt shadow, and especically because the kernel's local_irq_enable() distills > down to a bare STI. I still don't agree with you on this at all. I would like to hear what other KVM developers think about it. safe_halt actually is a example for function that abstacts away the nop - just what I want to do. A comment in irq_enable() about that nop also is fine to have. Best regards, Maxim Levitsky >
