xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH RFC 4/9] x86/misc: Early cleanup
Date: Thu, 15 May 2014 11:38:12 +0100	[thread overview]
Message-ID: <53749914.4090708@citrix.com> (raw)
In-Reply-To: <5374B3C702000078000128C7@mail.emea.novell.com>

On 15/05/14 11:32, Jan Beulich wrote:
>>>> On 15.05.14 at 11:48, <andrew.cooper3@citrix.com> wrote:
>> * machine_restart() disables the watchdog itself, covering itself from other
>>   callers.  Drop superfluous braces and watchdog_disable() from panic().
> Hmm, panic() is common code, and machine_restart()'s property of
> calling watchdog_disable() is x86-specific. I realize that ARM just
> doesn't have a watchdog right now, but do we really want to make
> it a requirement that each watchdog-capable arch does that in
> machine_restart()? Otoh an arch that can tolerate its watchdog
> being disabled over the restart attempt would then not get this
> enforced onto it (in which case only the description above would need
> a little tweaking).

machine_halt() needs just as much watchdog intervention as
machine_restart(), yet that was asymmetric.

I would argue that it is up to the arch to know whether playing with the
watchdog is needed for these things.

>
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -375,21 +375,18 @@ void vcpu_show_execution_state(struct vcpu *v)
>>      vcpu_unpause(v);
>>  }
>>  
>> -static char *trapstr(int trapnr)
>> -{
>> -    static char *strings[] = { 
>> -        "divide error", "debug", "nmi", "bkpt", "overflow", "bounds", 
>> -        "invalid opcode", "device not available", "double fault", 
>> -        "coprocessor segment", "invalid tss", "segment not found", 
>> -        "stack error", "general protection fault", "page fault", 
>> -        "spurious interrupt", "coprocessor error", "alignment check", 
>> +static const char *trapstr(unsigned int trapnr)
>> +{
>> +    static char *strings[] = {
> If you already touch this, and if you already make the function
> return const char *, then this also wants to become const char *const.
>
> Jan
>

Will do.

~Andrew

  reply	other threads:[~2014-05-15 10:38 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-15  9:48 [PATCH RFC 0/9] x86: Improvements to trap handling Andrew Cooper
2014-05-15  9:48 ` [PATCH RFC 1/9] x86/traps: Names for system descriptor types Andrew Cooper
2014-05-15  9:56   ` Andrew Cooper
2014-05-15 10:08   ` Jan Beulich
2014-05-15 10:26     ` Andrew Cooper
2014-05-15 12:10       ` Jan Beulich
2014-05-15  9:48 ` [PATCH RFC 2/9] x86/traps: Make panic and reboot paths safe during early boot Andrew Cooper
2014-05-15 10:19   ` Jan Beulich
2014-05-15 10:53     ` Andrew Cooper
2014-05-15 12:12       ` Jan Beulich
2014-05-15 15:46         ` Andrew Cooper
2014-05-15 15:59           ` Jan Beulich
2014-05-15  9:48 ` [PATCH RFC 3/9] x86/traps: Make the main trap handlers safe for use early during Xen boot Andrew Cooper
2014-05-15 10:20   ` Jan Beulich
2014-05-15  9:48 ` [PATCH RFC 4/9] x86/misc: Early cleanup Andrew Cooper
2014-05-15 10:32   ` Jan Beulich
2014-05-15 10:38     ` Andrew Cooper [this message]
2014-05-15  9:48 ` [PATCH RFC 5/9] x86/traps: Functional prep work Andrew Cooper
2014-05-15 10:36   ` Jan Beulich
2014-05-15 10:45     ` Andrew Cooper
2014-05-15 12:15       ` Jan Beulich
2014-05-15 12:42         ` Andrew Cooper
2014-05-15  9:48 ` [PATCH RFC 6/9] x86/boot: Install trap handlers much earlier on boot Andrew Cooper
2014-05-15 10:53   ` Jan Beulich
2014-05-15 11:05     ` Andrew Cooper
2014-05-15 12:21       ` Jan Beulich
2014-05-15  9:48 ` [PATCH RFC 7/9] x86/boot: Drop pre-C IDT patching Andrew Cooper
2014-05-15  9:48 ` [PATCH RFC 8/9] x86/irqs: Move interrupt-stub generation out of C Andrew Cooper
2014-05-15 13:06   ` Jan Beulich
2014-05-15  9:48 ` [PATCH RFC 9/9] x86/misc: Post cleanup Andrew Cooper
2014-05-15 13:14   ` Jan Beulich
2014-05-15 13:17     ` Andrew Cooper
2014-05-16  8:49 ` [PATCH RFC 0/9] x86: Improvements to trap handling Wu, Feng

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=53749914.4090708@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=keir@xen.org \
    --cc=tim@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).