All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: "Keir (Xen.org)" <keir@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH RFC] hvm: Allow triple fault to imply crash rather than reboot
Date: Mon, 4 Feb 2013 14:50:39 +0000	[thread overview]
Message-ID: <510FCABF.7010003@citrix.com> (raw)
In-Reply-To: <510FD7C002000078000BB8F0@nat28.tlf.novell.com>

On 04/02/13 14:46, Jan Beulich wrote:
>>>> On 04.02.13 at 15:25, Andrew Cooper <andrew.cooper3@citrix.com> 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.
> Makes sense to me; minor nits below (no need to resend just
> because of that, but would be nice to be addressed if you had
> to rev the patch anyway).
>
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -1233,9 +1233,14 @@ void hvm_hlt(unsigned long rflags)
>>  void hvm_triple_fault(void)
>>  {
>>      struct vcpu *v = current;
>> +    struct domain * d = v->domain;
> Stray blank.

Space between * and d ?

>
>> +    u8 reason = d->arch.hvm_domain.params[HVM_PARAM_TRIPLE_FAULT_CRASH]
>> +        ? SHUTDOWN_crash : SHUTDOWN_reboot;
>> +
>>      gdprintk(XENLOG_INFO, "Triple fault on VCPU%d - "
>> -             "invoking HVM system reset.\n", v->vcpu_id);
>> -    domain_shutdown(v->domain, SHUTDOWN_reboot);
>> +             "invoking HVM system %s.\n", v->vcpu_id,
>> +             reason == SHUTDOWN_crash ? "crash" : "reboot");
>> +    domain_shutdown(v->domain, reason);
> So you have d cached in a local variable now, yet you still use
> v->domain here?

Doh - missed that.

>
> Also, I'd prefer for the message to continue to say "reset".
>
> Jan
>
Ok - I will respin and send as non-rfc.

  reply	other threads:[~2013-02-04 14:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-04 14:25 [PATCH RFC] hvm: Allow triple fault to imply crash rather than reboot Andrew Cooper
2013-02-04 14:46 ` Jan Beulich
2013-02-04 14:50   ` Andrew Cooper [this message]
2013-02-04 15:26 ` Ian Campbell
2013-02-04 16:46   ` Keir Fraser
2013-02-04 17:12     ` Andrew Cooper
2013-02-04 17:55       ` Keir Fraser
  -- strict thread matches above, loose matches on Subject: below --
2016-11-07 12:56 Xuquan (Quan Xu)
2016-11-07 13:12 ` Andrew Cooper
2016-11-07 13:18   ` Xuquan (Quan Xu)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=510FCABF.7010003@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=keir@xen.org \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.