Re: [PATCH RFC] hvm: Allow triple fault to imply crash rather than reboot

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 04/02/13 16:46, Keir Fraser wrote:
> On 04/02/2013 15:26, "Ian Campbell" <Ian.Campbell@citrix.com> wrote:
>
>> On Mon, 2013-02-04 at 14:25 +0000, Andrew Cooper wrote:
>>> While the triple fault action on native hardware will result in a system
>>> reset, any modern operating system can and will make use of less violent
>>> reboot methods.  As a result, the most likely cause of a triple fault is a
>>> fatal software bug.
>>>
>>> This patch allows the toolstack to indicate that a triple fault should mean a
>>> crash rather than a reboot.  The default of reboot still remains the same.
>> Just a random thought -- what about adding SHUTDOWN_triple_fault as an
>> explicit thing, then the toolstack can decide what to do?
> I kind of prefer that, although it will require changes to every toolstack.
>
> An alternative would be to do that, *and* still have the new HVM_PARAM, so
> that any SHUTDOWN_* code can be generated by a triple fault (including new
> SHUTDOWN_triple_fault) -- but defaulting to SHUTDOWN_reboot so that the
> default behaviour is still unchanged.
>
> Or, in any case, I'm not dead against the existing patch, it just seems less
> flexible than it could be. But maybe that flexibility is pointless.
>
>  -- Keir

I considered this approach originally, but decided against it.

SHUTDOWN_triple_fault would be meaningless as a standard SCHOP_shutdown
parameter, and having the toolstack differentiate between _crash and
_triple_fault seems pointless.

I thought that the ideal end result would be specifying

on_triple_fault="reboot"|"crash"

In the vm.cfg file

The on_{crash,reboot} actions would still then take effect as usual.

Having said that, if _triple_fault is preferred, I am not overly
attached to this specific implementation.


If it isn't obvious, the motivation behind this patch is because I am
currently chasing a windows triple fault on Xen-4.2.  It appears machine
specific, but related to our PV driver, and takes a long time to
reproduce.  Having automated tests fail soon with a triple fault is
better than having the domain in question sit in a reboot loop until the
hour long timeout kicks in.

~Andrew