All of lore.kernel.org
 help / color / mirror / Atom feed
From: oleksii.kurochko@gmail.com
To: Jan Beulich <jbeulich@suse.com>
Cc: Alistair Francis <alistair.francis@wdc.com>,
	Bob Eshleman <bobbyeshleman@gmail.com>,
	Connor Davis <connojdavis@gmail.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v12 1/3] xen/riscv: enable GENERIC_BUG_FRAME
Date: Tue, 06 Aug 2024 12:11:56 +0200	[thread overview]
Message-ID: <89d6b01ac85899c85f1dbfdaa907435e12de75c2.camel@gmail.com> (raw)
In-Reply-To: <0245feaa-6cf2-4f44-843f-38cdcc6b7a42@suse.com>

On Mon, 2024-08-05 at 17:41 +0200, Jan Beulich wrote:
> On 02.08.2024 15:54, Oleksii Kurochko wrote:
> > Enable GENERIC_BUG_FRAME to support BUG(), WARN(), ASSERT,
> > and run_in_exception_handler().
> > 
> > The 0x0000 opcode is used for BUG_INSTR, which, when macros from
> > <xen/bug.h> are used, triggers an exception with the
> > ILLEGAL_INSTRUCTION cause.
> > This opcode is encoded as a 2-byte instruction and is invalid if
> > CONFIG_RISCV_ISA_C is enabled or not.
> 
> Yes, but there's a caveat: Without the C extension instructions have
> to be aligned on 32-bit boundaries. You can't just go and insert a
> 16-bit item there. When RISCV_ISA_C is not set, I think you want to
> insert two such 16-bit zeroes. Beware of an alignment handling bug
> in the assembler - don't think of using an alignment directive here.
Then probably it will be better to define BUG_INSTR as:
 #define BUG_INSTR "UNIMP"
and let compiler to provide proper opcode.

Or define BUG_INSTRT always as 0x00000000 will be better?
> 
> 
> > --- a/xen/arch/riscv/include/asm/bug.h
> > +++ b/xen/arch/riscv/include/asm/bug.h
> > @@ -9,7 +9,11 @@
> >  
> >  #ifndef __ASSEMBLY__
> >  
> > -#define BUG_INSTR "ebreak"
> > +#include <xen/stringify.h>
> > +
> > +#define BUG_OPCODE  0x0000
> 
> You don't really use this other than ...
> 
> > +#define BUG_INSTR ".hword " __stringify(BUG_OPCODE)
> 
> ... here - does this really warrant a separate #define _and_
> inclusion of
> stringify.h?
> 
> Furthermore you want to avoid using .hword (or any data generating
> directive), to avoid disturbing disassembly. Please use .insn if at
> all
> possible. I understand though that in certain cases you won't be able
> to
> use .insn. Yet for the common case (more recent binutils) you'd still
> better avoid .hword or alike, imo.
> 
> > @@ -103,7 +104,29 @@ static void do_unexpected_trap(const struct
> > cpu_user_regs *regs)
> >  
> >  void do_trap(struct cpu_user_regs *cpu_regs)
> >  {
> > -    do_unexpected_trap(cpu_regs);
> > +    register_t pc = cpu_regs->sepc;
> > +    unsigned long cause = csr_read(CSR_SCAUSE);
> > +
> > +    switch ( cause )
> > +    {
> > +    case CAUSE_ILLEGAL_INSTRUCTION:
> > +        if ( do_bug_frame(cpu_regs, pc) >= 0 )
> > +        {
> > +            if ( !(is_kernel_text(pc) || is_kernel_inittext(pc)) )
> > +            {
> > +                printk("Something wrong with PC: %#lx\n", pc);
> > +                die();
> > +            }
> > +
> > +            cpu_regs->sepc += GET_INSN_LENGTH(*(uint16_t *)pc);
> > +
> > +            break;
> > +        }
> > +
> > +    default:
> 
> The falling-through here wants annotating, preferably with the
> pseudo-
> keyword.
What kind of pseudo-keyword? I though about /* goto default */ to
underline that CAUSE_ILLEGAL_INSTRUCTION should be close to "default:".

~ Oleksii
> > +        do_unexpected_trap(cpu_regs);
> > +        break;
> > +    }
> >  }
> 



  reply	other threads:[~2024-08-06 10:12 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-02 13:54 [PATCH v12 0/3] RISCV basic exception handling implementation Oleksii Kurochko
2024-08-02 13:54 ` [PATCH v12 1/3] xen/riscv: enable GENERIC_BUG_FRAME Oleksii Kurochko
2024-08-05 15:41   ` Jan Beulich
2024-08-06 10:11     ` oleksii.kurochko [this message]
2024-08-06 14:23       ` Jan Beulich
2024-08-02 13:54 ` [PATCH v12 2/3] xen/riscv: test basic exception handling stuff Oleksii Kurochko
2024-08-02 13:54 ` [PATCH v12 3/3] xen/riscv: refactor decode_trap_cause() Oleksii Kurochko
2024-08-05  6:20   ` Jan Beulich
2024-08-05  9:14     ` oleksii.kurochko

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=89d6b01ac85899c85f1dbfdaa907435e12de75c2.camel@gmail.com \
    --to=oleksii.kurochko@gmail.com \
    --cc=alistair.francis@wdc.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=bobbyeshleman@gmail.com \
    --cc=connojdavis@gmail.com \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.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.