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

[Keir Fraser <keir@xxxxxxx>]

On 04/02/2013 17:12, "Andrew Cooper" <andrew.cooper3@xxxxxxxxxx> wrote:

>> 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.

How about letting the HVM_PARAM accept any SHUTDOWN_ code? Rather than being
a boolean? That's a trivial change, just seems a bit cleaner than a boolean
to me.

Also adding the SHUTDOWN_triple_fault seemed like a maybe-nice-to-have. I
don't really care that much, and indeed it probably is 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.

No let's drop the idea of a SHUTDOWN_triple_fault. :)

> 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.

Yep, agreed, a patch along these lines of some sort is a very good idea!

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel