From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH RFC] hvm: Allow triple fault to imply crash rather than reboot Date: Mon, 04 Feb 2013 17:55:57 +0000 Message-ID: References: <510FEBF5.1060708@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <510FEBF5.1060708@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper Cc: Ian Campbell , Jan Beulich , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 04/02/2013 17:12, "Andrew Cooper" 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