On 17.09.20 17:33, Richard Henderson wrote: > On 9/17/20 4:54 AM, David Hildenbrand wrote: >> Recent upstream Linux uses the MONITOR CALL instruction for things like >> BUG_ON() and WARN_ON(). We currently inject an operation exception when >> we hit a MONITOR CALL instruction - which is wrong, as the instruction >> is not glued to specific CPU features. >> >> Doing a simple WARN_ON_ONCE() currently results in a panic: >> [ 18.162801] illegal operation: 0001 ilc:2 [#1] SMP >> [ 18.162889] Modules linked in: >> [...] >> [ 18.165476] Kernel panic - not syncing: Fatal exception: panic_on_oops >> >> With a proper implementation, we now get: >> [ 18.242754] ------------[ cut here ]------------ >> [ 18.242855] WARNING: CPU: 7 PID: 1 at init/main.c:1534 [...] >> [ 18.242919] Modules linked in: >> [...] >> [ 18.246262] ---[ end trace a420477d71dc97b4 ]--- >> [ 18.259014] Freeing unused kernel memory: 4220K >> >> To be able to translate it to a NOP easily, mangle the 16 monitor masks >> bits from the cr8 into the TB flags. > > This is a rare situation that does not warrant the use of TB flags. Better to
I think it can be used for tracing and such, so quite excessively - but yeah, at least in Linux it should be rare. > unconditionally call helper_monitor_event, and have the helper function test > the runtime value of cr8. If the event is disabled, the helper simply > returns. > > It should be simpler to write, as well, not having to do this: > Was too appealing to optimize. Well, doing it in a handler also makes the implementation of monitor-event counting easier. -- Thanks, David / dhildenb
