All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Oleksii <oleksii.kurochko@gmail.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Gianluca Guida <gianluca@rivosinc.com>,
	Bob Eshleman <bobbyeshleman@gmail.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Connor Davis <connojdavis@gmail.com>,
	Julien Grall <julien@xen.org>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v5 4/7] xen/riscv: introduce decode_cause() stuff
Date: Wed, 22 Mar 2023 14:46:18 +0100	[thread overview]
Message-ID: <486cf6f9-4e28-17b5-3ab3-31272955926b@suse.com> (raw)
In-Reply-To: <98a891792446e72d910ee49a62c7e3b3d2d6c186.camel@gmail.com>

On 22.03.2023 14:32, Oleksii wrote:
> On Wed, 2023-03-22 at 13:26 +0100, Jan Beulich wrote:
>> But as said before - I'm unconvinced this approach will scale,
>> because
>> you'll need to apply the wrapper to anything which can be reached
>> prior
>> to you enabling the MMU. Whether you can contain this to RISC-V-only
>> code is unclear; I don't think it'll be acceptable to change any part
>> of common code to meet your special needs.
> But it looks like it is only two places where it should be done:
> 1. As you mentioned LINK_TO_LOAD() should be applied for trap_causes.
> 2. And it should be applied inside do_bug_frame() for getting an
> start/end address of bug_frame. I want to note that do_bug_frame() will
> be removed after RISC-V is ready to switch to generic bug
> implementation.
> 
> The next step after the current patch series is merged is to enable
> MMU, so it shouldn't be new use cases where it is needed to use
> LINK_TO_LOAD().

I'm not convinced. You can't stick to using earlyprintk only beyond
very short term. Yet I expect you also don't want to use

    if ( early )
        earlyprintk();
    else
        printk();

everywhere in exception handling code (and anywhere else in code
which is reachable before the MMU is turned on). This extends to
uses of BUG() and alike in such early code, which - when they
trigger - want to use printk() (only). Whether printk(), somehow,
involves an array access similar to the ones you're presently
aware of you simply shouldn't depend on (it's an implementation
detail in a separate subsystem).

> If it is not acceptable to change any part of common code ( as I
> understand in this case it is do_unexpected_trap() and all that is
> called inside it ) have I to introduce two types of function
> do_unexpected_trap() for when MMU is enabled and not?

By "common code" I mean code outside of arch/riscv/. And I
sincerely hope you / we can get away without duplicated functions.

Jan


  reply	other threads:[~2023-03-22 13:46 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-16 14:39 [PATCH v5 0/7] RISCV basic exception handling implementation Oleksii Kurochko
2023-03-16 14:39 ` [PATCH v5 1/7] xen/riscv: introduce boot information structure Oleksii Kurochko
2023-03-21 11:17   ` Jan Beulich
2023-03-21 14:30     ` Oleksii
2023-03-21 11:56   ` Andrew Cooper
2023-03-22 13:12     ` Oleksii
2023-03-16 14:39 ` [PATCH v5 2/7] xen/riscv: initialize boot_info structure Oleksii Kurochko
2023-03-21 11:27   ` Jan Beulich
2023-03-21 14:43     ` Oleksii
2023-03-16 14:39 ` [PATCH v5 3/7] xen/riscv: introduce dummy <asm/bug.h> Oleksii Kurochko
2023-03-21 17:21   ` Julien Grall
2023-03-22 10:09     ` Oleksii
2023-03-22 10:27       ` Jan Beulich
2023-03-22 13:14         ` Oleksii
2023-03-16 14:39 ` [PATCH v5 4/7] xen/riscv: introduce decode_cause() stuff Oleksii Kurochko
2023-03-21 17:33   ` Julien Grall
2023-03-22 10:20     ` Oleksii
2023-03-22 12:26       ` Jan Beulich
2023-03-22 13:32         ` Oleksii
2023-03-22 13:46           ` Jan Beulich [this message]
2023-03-22 14:59             ` Oleksii
2023-03-22 15:21               ` Jan Beulich
2023-03-16 14:39 ` [PATCH v5 5/7] xen/riscv: introduce trap_init() Oleksii Kurochko
2023-03-21 17:42   ` Julien Grall
2023-03-22 11:33     ` Oleksii
2023-03-22 12:14       ` Julien Grall
2023-03-22 13:40         ` Oleksii
2023-03-22 13:51           ` Julien Grall
2023-03-22 14:02             ` Jan Beulich
2023-03-22 14:49             ` Oleksii
2023-03-16 14:39 ` [PATCH v5 6/7] xen/riscv: introduce an implementation of macros from <asm/bug.h> Oleksii Kurochko
2023-03-16 14:39 ` [PATCH v5 7/7] xen/riscv: test basic handling stuff 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=486cf6f9-4e28-17b5-3ab3-31272955926b@suse.com \
    --to=jbeulich@suse.com \
    --cc=alistair.francis@wdc.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=bobbyeshleman@gmail.com \
    --cc=connojdavis@gmail.com \
    --cc=gianluca@rivosinc.com \
    --cc=julien@xen.org \
    --cc=oleksii.kurochko@gmail.com \
    --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.