On 02.10.2019 15:24, Boris Ostrovsky wrote: > On 10/2/19 3:40 AM, Jan Beulich wrote: >> On 01.10.2019 17:16, Boris Ostrovsky wrote: >>> Currently execution of panic() continues until Xen's panic notifier >>> (xen_panic_event()) is called at which point we make a hypercall that >>> never returns. >>> >>> This means that any notifier that is supposed to be called later as >>> well as significant part of panic() code (such as pstore writes from >>> kmsg_dump()) is never executed. >> Back at the time when this was introduced into the XenoLinux tree, >> I think this behavior was intentional for at least DomU-s. I wonder >> whether you wouldn't want your change to further distinguish Dom0 >> and DomU behavior. > > Do you remember what the reason for that was?
I can only guess that the thinking probably was that e.g. external dumping (by the tool stack) would be more reliable (including but not limited to this meaning less change of state from when the original crash reason was detected) than having the domain dump itself. > I think having ability to call kmsg_dump() on a panic is a useful thing > to have for domUs as well. Besides, there may be other functionality > added post-notifiers in panic() in the future. Or another notifier may > be registered later with the same lowest priority. > > Is there a downside in allowing domUs to fall through panic() all the > way to emergency_restart()? See above. >>> There is no reason for xen_panic_event() to be this last point in >>> execution since panic()'s emergency_restart() will call into >>> xen_emergency_restart() from where we can perform our hypercall. >> Did you consider, as an alternative, to lower the notifier's >> priority? > > I didn't but that wouldn't help with the original problem that James > reported --- we'd still not get to kmsg_dump() call. True. I guess more control over the behavior needs to be given to the admin, as either approach has its up- and downsides Jan
