public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nicholas Piggin <npiggin@gmail.com>
To: Michael Ellerman <mpe@ellerman.id.au>,
	Segher Boessenkool <segher@kernel.crashing.org>
Cc: aik@ozlabs.ru, akpm@linux-foundation.org, alistair@popple.id.au,
	aneesh.kumar@linux.ibm.com, atrajeev@linux.vnet.ibm.com,
	benh@kernel.crashing.org, christophe.leroy@csgroup.eu,
	haren@linux.ibm.com, jniethe5@gmail.com,
	john.ogness@linutronix.de, kan.liang@linux.intel.com,
	kjain@linux.ibm.com, kvm-ppc@vger.kernel.org,
	leobras.c@gmail.com, linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, maddy@linux.ibm.com,
	mikey@neuling.org, msuchanek@suse.de, oleg@redhat.com,
	paulus@samba.org, peterx@redhat.com, peterz@infradead.org,
	pmladek@suse.com, ravi.bangoria@linux.ibm.com, rppt@kernel.org,
	Xiongwei Song <sxwjean@gmail.com>, Xiongwei Song <sxwjean@me.com>
Subject: Re: [PATCH v2] powerpc/traps: Enhance readability for trap types
Date: Thu, 01 Apr 2021 18:01:29 +1000	[thread overview]
Message-ID: <1617262858.ls37f2d81f.astroid@bobo.none> (raw)
In-Reply-To: <87im5620f3.fsf@mpe.ellerman.id.au>

Excerpts from Michael Ellerman's message of April 1, 2021 12:39 pm:
> Segher Boessenkool <segher@kernel.crashing.org> writes:
>> On Wed, Mar 31, 2021 at 08:58:17PM +1100, Michael Ellerman wrote:
>>> So perhaps:
>>> 
>>>   EXC_SYSTEM_RESET
>>>   EXC_MACHINE_CHECK
>>>   EXC_DATA_STORAGE
>>>   EXC_DATA_SEGMENT
>>>   EXC_INST_STORAGE
>>>   EXC_INST_SEGMENT
>>>   EXC_EXTERNAL_INTERRUPT
>>>   EXC_ALIGNMENT
>>>   EXC_PROGRAM_CHECK
>>>   EXC_FP_UNAVAILABLE
>>>   EXC_DECREMENTER
>>>   EXC_HV_DECREMENTER
>>>   EXC_SYSTEM_CALL
>>>   EXC_HV_DATA_STORAGE
>>>   EXC_PERF_MONITOR
>>
>> These are interrupt (vectors), not exceptions.  It doesn't matter all
>> that much, but confusing things more isn't useful either!  There can be
>> multiple exceptions that all can trigger the same interrupt.
> 
> Yeah I know, but I think that ship has already sailed as far as the
> naming we have in the kernel.

It has, but there are also several other ships also sailing in different 
directions. It could be worse though, at least they are not sideways in 
the Suez.

> We have over 250 uses of "exc", and several files called "exception"
> something.
> 
> Using "interrupt" can also be confusing because Linux uses that to mean
> "external interrupt".
> 
> But I dunno, maybe INT or VEC is clearer? .. or TRAP :)

We actually already have defines that follow Segher's suggestion, it's 
just that they're hidden away in a KVM header.

#define BOOK3S_INTERRUPT_SYSTEM_RESET   0x100
#define BOOK3S_INTERRUPT_MACHINE_CHECK  0x200
#define BOOK3S_INTERRUPT_DATA_STORAGE   0x300
#define BOOK3S_INTERRUPT_DATA_SEGMENT   0x380
#define BOOK3S_INTERRUPT_INST_STORAGE   0x400
#define BOOK3S_INTERRUPT_INST_SEGMENT   0x480
#define BOOK3S_INTERRUPT_EXTERNAL       0x500
#define BOOK3S_INTERRUPT_EXTERNAL_HV    0x502
#define BOOK3S_INTERRUPT_ALIGNMENT      0x600

It would take just a small amount of work to move these to general 
powerpc header, add #ifdefs for Book E/S where the numbers differ,
and remove the BOOK3S_ prefix.

I don't mind INTERRUPT_ but INT_ would be okay too. VEC_ actually
doesn't match what Book E does (which is some weirdness to map some
of them to match Book S but not all, arguably we should clean that
up too and just use vector numbers consistently, but the INTERRUPT_
prefix would still be valid if we did that).

BookE KVM entry will still continue to use a different convention
there so I would leave all those KVM defines in place for now, we
might do another pass on them later.

Thanks,
Nick

  reply	other threads:[~2021-04-01  8:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-30 15:04 [PATCH v2] powerpc/traps: Enhance readability for trap types Xiongwei Song
2021-03-31  9:58 ` Michael Ellerman
2021-03-31 21:25   ` Segher Boessenkool
2021-04-01  2:39     ` Michael Ellerman
2021-04-01  8:01       ` Nicholas Piggin [this message]
2021-04-01 16:16         ` Segher Boessenkool
2021-04-05 12:10         ` Xiongwei Song
     [not found]     ` <CAEVVKH8XDiEGHjXj6sJAHynhwqKWpNqj_Ws03AqwNjR8OmHf5w@mail.gmail.com>
2021-04-01 16:11       ` Segher Boessenkool
2021-04-02  0:36         ` Nicholas Piggin
2021-04-05 12:18           ` Xiongwei Song
2021-04-05 12:03         ` Xiongwei Song

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=1617262858.ls37f2d81f.astroid@bobo.none \
    --to=npiggin@gmail.com \
    --cc=aik@ozlabs.ru \
    --cc=akpm@linux-foundation.org \
    --cc=alistair@popple.id.au \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=atrajeev@linux.vnet.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=christophe.leroy@csgroup.eu \
    --cc=haren@linux.ibm.com \
    --cc=jniethe5@gmail.com \
    --cc=john.ogness@linutronix.de \
    --cc=kan.liang@linux.intel.com \
    --cc=kjain@linux.ibm.com \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=leobras.c@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.ibm.com \
    --cc=mikey@neuling.org \
    --cc=mpe@ellerman.id.au \
    --cc=msuchanek@suse.de \
    --cc=oleg@redhat.com \
    --cc=paulus@samba.org \
    --cc=peterx@redhat.com \
    --cc=peterz@infradead.org \
    --cc=pmladek@suse.com \
    --cc=ravi.bangoria@linux.ibm.com \
    --cc=rppt@kernel.org \
    --cc=segher@kernel.crashing.org \
    --cc=sxwjean@gmail.com \
    --cc=sxwjean@me.com \
    /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