From: Jessica Clarke <jrtc27@jrtc27.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Matthew Wilcox <willy@infradead.org>,
"Lad, Prabhakar" <prabhakar.csengg@gmail.com>,
Linux-MM <linux-mm@kvack.org>,
linux-riscv <linux-riscv@lists.infradead.org>,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>, Palmer Dabbelt <palmer@dabbelt.com>,
Arnd Bergmann <arnd@arndb.de>, Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Geert Uytterhoeven <geert.uytterhoeven@gmail.com>,
Fabrizio Castro <fabrizio.castro.jz@renesas.com>,
Biju Das <biju.das.jz@bp.renesas.com>,
Chris Paterson <Chris.Paterson2@renesas.com>
Subject: Re: [QUERY]: Block region to mmap
Date: Wed, 1 Feb 2023 07:05:22 +0000 [thread overview]
Message-ID: <11BE997B-93C7-4D38-99BF-FD025A1FB945@jrtc27.com> (raw)
In-Reply-To: <Y9oHT1D1X9cdHLr0@infradead.org>
On 1 Feb 2023, at 06:31, Christoph Hellwig <hch@infradead.org> wrote:
> On Mon, Jan 30, 2023 at 03:24:40PM +0000, Matthew Wilcox wrote:
>>> Basically we are making use of the memory protection unit (MPU) so
>>> that only M-mode is allowed to access this region and S/U modes are
>>> blocked.
>>
>> This sounds like RISC-V terminology. I have no idea what M, S or U
>> modes are (Supervisor and User, I'd guess for the last two?)
>
>
> Yes, M = Machine, S = Supervisor, and U = User.
> M omde is the absolutele worst idea of RISC-V and basically a mix
> of microcode and super-SMM mode.
>
>> Before we go too deeply into it, how much would it cost to buy all of
>> these parts and feed them into a shredder? I'm not entirely joking;
>> if it's less than the software engineering time it'd take to develop
>> and support this feature, we should do it.
>
> The above suggests this is in no way an actual hardware problem, but the
> stupid decision is done in the M-Mode firmware. I think it is very
> reasonable to simply not support the devices in Linux until the firmware
> is fixed.
No, it really is a hardware spec violation. Virtual addresses within
the magic range bypass translation with no way to turn it off. The
firmware is being (has been?) patched to block those accesses at the
physical memory protection level so any attempt to use those virtual
addresses will fault, but if Linux wants to support this cursed
hardware and its gross spec violation then it needs to forbid any
allocation of the VA range.
This magic range also overlaps with the default base address used for
both GNU ld and LLVM LLD, for added entertainment, so almost every
position-dependent binary that exists in the world for RISC-V cannot be
run on this hardware. One could change that for future binaries, but
that doesn’t seem right to me... IMO this hardware is even more “not
RISC-V” than the D1 with its page table mess, but I don’t think we’ll
ever see RISC-V International come out and say that, so it’s up to the
open-source communities to decide what they want to support and what
they view as too much of a violation to be acceptable.
Jess
next prev parent reply other threads:[~2023-02-01 7:05 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-25 12:30 Lad, Prabhakar
2023-01-26 14:37 ` Matthew Wilcox
2023-01-30 10:53 ` Lad, Prabhakar
2023-01-30 15:24 ` Matthew Wilcox
2023-02-01 6:31 ` Christoph Hellwig
2023-02-01 7:05 ` Jessica Clarke [this message]
2023-02-01 8:05 ` Arnd Bergmann
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=11BE997B-93C7-4D38-99BF-FD025A1FB945@jrtc27.com \
--to=jrtc27@jrtc27.com \
--cc=Chris.Paterson2@renesas.com \
--cc=arnd@arndb.de \
--cc=biju.das.jz@bp.renesas.com \
--cc=devicetree@vger.kernel.org \
--cc=fabrizio.castro.jz@renesas.com \
--cc=geert.uytterhoeven@gmail.com \
--cc=hch@infradead.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-mm@kvack.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=prabhakar.csengg@gmail.com \
--cc=robh+dt@kernel.org \
--cc=willy@infradead.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