Messages in this thread | | | From | ron minnich <> | Date | Tue, 3 Oct 2023 09:37:51 -0600 | Subject | Re: [PATCH 0/7] Add support to handle misaligned accesses in S-mode |
| |
While it is true that it violates the spec today, given the fluidity of the spec of the last 10 years, I'm not sure that matters :-)
Anyway, that's out of scope for this discussion, though I appreciate your clarification. I'll bring it up elsewhere.
Clement points out that this series would work fine if that bit were hardwired to 1, which is all I care about.
thanks
On Mon, Oct 2, 2023 at 4:23 PM Jessica Clarke <jrtc27@jrtc27.com> wrote: > > On 2 Oct 2023, at 16:32, ron minnich <rminnich@gmail.com> wrote: > > > > This was a very interesting read. One other thought crossed my mind, > > which is that a RISC-V implementation might make the alignment > > delegation hard-wired to always delegate to S mode. I.e, the bit might > > be WARL and always 1. For what I'm doing, this would actually be > > pretty convenient. Just want to make sure this code can accommodate > > that -- wdyt? > > Such an implementation would violate the spec: > > An implementation shall not have any bits of medeleg be read-only > one, i.e., any synchronous trap that can be delegated must support not > being delegated. > > Supporting that is thus out of scope. > > Jess > > > We have found lots of value in our experiments with delegating > > alignment traps to Linux -- not least because they tend to locate > > problems in the kernel :-) -- we've found issues in module loading, > > early startup (there's a needed .align2 directive for sbi secondary > > startup, AFAICT) and the timing code for misaligned load/store > > handling. > > > > I don't know how you test this unaligned trap handling, but it might > > be worthwhile to work that out. You can test via oreboot and the > > visionfive2, save we have not figured out why SMP startup is going > > wrong, yet :-), so we're not as feature-complete as needed. But soon. > > > > Thanks! > > > > On Mon, Oct 2, 2023 at 5:19 AM Clément Léger <cleger@rivosinc.com> wrote: > >> > >> > >> > >> On 02/10/2023 12:49, Conor Dooley wrote: > >>> On Mon, Oct 02, 2023 at 09:40:04AM +0200, Clément Léger wrote: > >>>> > >>>> > >>>> On 30/09/2023 11:23, Conor Dooley wrote: > >>>>> On Tue, Sep 26, 2023 at 05:03:09PM +0200, Clément Léger wrote: > >>>>>> Since commit 61cadb9 ("Provide new description of misaligned load/store > >>>>>> behavior compatible with privileged architecture.") in the RISC-V ISA > >>>>>> manual, it is stated that misaligned load/store might not be supported. > >>>>>> However, the RISC-V kernel uABI describes that misaligned accesses are > >>>>>> supported. In order to support that, this series adds support for S-mode > >>>>>> handling of misaligned accesses as well support for prctl(PR_UNALIGN). > >>>>>> > >>>>>> Handling misaligned access in kernel allows for a finer grain control > >>>>>> of the misaligned accesses behavior, and thanks to the prctl call, can > >>>>>> allow disabling misaligned access emulation to generate SIGBUS. User > >>>>>> space can then optimize its software by removing such access based on > >>>>>> SIGBUS generation. > >>>>>> > >>>>>> Currently, this series is useful for people that uses a SBI that does > >>>>>> not handled misaligned traps. In a near future, this series will make > >>>>>> use a SBI extension [1] allowing to request delegation of the > >>>>>> misaligned load/store traps to the S-mode software. This extension has > >>>>>> been submitted for review to the riscv tech-prs group. An OpenSBI > >>>>>> implementation for this spec is available at [2]. > >>>>>> > >>>>>> This series can be tested using the spike simulator [3] and an openSBI > >>>>>> version [4] which allows to always delegate misaligned load/store to > >>>>>> S-mode. > >>>>> > >>>>> Some patches in this series do not build for any configs, some are > >>>>> broken for clang builds and others are broken for nommu. Please try to> build test this more thoroughly before you submit the next version. > >>>> > >>>> Hi Conor, > >>>> > >>>> Thanks for the feedback, I'll check that. > >>>> > >>>>> > >>>>> Also, AIUI, this series should be marked RFC since the SBI extension > >>>>> this relies on has not been frozen. > >>>> > >>>> This series does not actually uses the SBI extension but provides a way > >>>> to detect if misaligned accesses are not handled by hardware nor by the > >>>> SBI. It has been reported by Ron & Daniel they they have a minimal SBI > >>>> implementation that does not handle misaligned accesses and that they > >>>> would like to make use of the PR_SET_UNALIGN feature. This is what this > >>>> series addresses (and thus does not depend on the mentioned SBI extension). > >>> > >>> Ah, I must have misread then. Apologies. > >> > >> No worries, maybe I should actually remove this from the cover letter to > >> avoid any confusion ! > >> > >> Clément > > > > _______________________________________________ > > linux-riscv mailing list > > linux-riscv@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-riscv >
| |