From: Palmer Dabbelt <palmer@sifive.com> To: vladimir.murzin@arm.com Cc: Damien Le Moal <Damien.LeMoal@wdc.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Paul Walmsley <paul.walmsley@sifive.com>, linux-riscv@lists.infradead.org, Christoph Hellwig <hch@lst.de> Subject: Re: RISC-V nommu support v2 Date: Tue, 25 Jun 2019 00:31:25 -0700 (PDT) Message-ID: <mhng-6f11ed95-e3f3-41dc-93c5-1576928b373b@palmer-si-x1e> (raw) In-Reply-To: <d4fd824d-03ff-e8ab-b19f-9e5ef5c22449@arm.com> On Mon, 24 Jun 2019 06:08:50 PDT (-0700), vladimir.murzin@arm.com wrote: > On 6/24/19 12:54 PM, Christoph Hellwig wrote: >> On Mon, Jun 24, 2019 at 12:47:07PM +0100, Vladimir Murzin wrote: >>> Since you are using binfmt_flat which is kind of 32-bit only I was expecting to see >>> CONFIG_COMPAT (or something similar to that, like ILP32) enabled, yet I could not >>> find it. >> >> There is no such thing in RISC-V. I don't know of any 64-bit RISC-V >> cpu that can actually run 32-bit RISC-V code, although in theory that >> is possible. There also is nothing like the x86 x32 or mips n32 mode >> available either for now. >> >> But it turns out that with a few fixes to binfmt_flat it can run 64-bit >> binaries just fine. I sent that series out a while ago, and IIRC you >> actually commented on it. >> > > True, yet my observation was that elf2flt utility assumes that address > space cannot exceed 32-bit (for header and absolute relocations). So, > from my limited point of view straightforward way to guarantee that would > be to build incoming elf in 32-bit mode (it is why I mentioned COMPAT/ILP32). > > Also one of your patches expressed somewhat related idea > > "binfmt_flat isn't the right binary format for huge executables to > start with" > > Since you said there is no support for compat/ilp32, probably I'm missing some > toolchain magic? > > Cheers > Vladimir To: Christoph Hellwig <hch@lst.de> CC: vladimir.murzin@arm.com CC: Christoph Hellwig <hch@lst.de> CC: Paul Walmsley <paul.walmsley@sifive.com> CC: Damien Le Moal <Damien.LeMoal@wdc.com> CC: linux-riscv@lists.infradead.org CC: linux-mm@kvack.org CC: linux-kernel@vger.kernel.org Subject: Re: RISC-V nommu support v2 In-Reply-To: <20190624131633.GB10746@lst.de> On Mon, 24 Jun 2019 06:16:33 PDT (-0700), Christoph Hellwig wrote: > On Mon, Jun 24, 2019 at 02:08:50PM +0100, Vladimir Murzin wrote: >> True, yet my observation was that elf2flt utility assumes that address >> space cannot exceed 32-bit (for header and absolute relocations). So, >> from my limited point of view straightforward way to guarantee that would >> be to build incoming elf in 32-bit mode (it is why I mentioned COMPAT/ILP32). >> >> Also one of your patches expressed somewhat related idea >> >> "binfmt_flat isn't the right binary format for huge executables to >> start with" >> >> Since you said there is no support for compat/ilp32, probably I'm missing some >> toolchain magic? > > There is no magic except for the tiny elf2flt patch, which for > now is just in the buildroot repo pointed to in the cover letter > (and which I plan to upstream once the kernel support has landed > in Linus' tree). We only support 32-bit code and data address spaces, > but we otherwise use the normal RISC-V ABI, that is 64-bit longs and > pointers. The medlow code model on RISC-V essentially enforces this -- technically it enforces a 32-bit region centered around address 0, but it's not that hard to stay away from negative addresses. That said, as long as elf2flt gives you an error it should be fine because all medlow is going to do is give you a different looking error message. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply index Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-06-24 5:42 Christoph Hellwig 2019-06-24 5:42 ` [PATCH 01/17] mm: provide a print_vma_addr stub for !CONFIG_MMU Christoph Hellwig 2019-06-24 5:42 ` [PATCH 02/17] mm: stub out all of swapops.h " Christoph Hellwig 2019-06-24 5:42 ` [PATCH 03/17] mm/nommu: fix the MAP_UNINITIALIZED flag Christoph Hellwig 2019-06-24 5:42 ` [PATCH 04/17] irqchip/sifive-plic: set max threshold for ignored handlers Christoph Hellwig 2019-06-24 5:42 ` [PATCH 05/17] riscv: use CSR_SATP instead of the legacy sptbr name in switch_mm Christoph Hellwig 2019-07-01 18:53 ` Atish Patra 2019-06-24 5:43 ` [PATCH 06/17] riscv: refactor the IPI code Christoph Hellwig 2019-06-24 5:43 ` [PATCH 07/17] riscv: abstract out CSR names for supervisor vs machine mode Christoph Hellwig 2019-07-01 18:37 ` Atish Patra 2019-06-24 5:43 ` [PATCH 08/17] riscv: improve the default power off implementation Christoph Hellwig 2019-07-01 21:07 ` Atish Patra 2019-06-24 5:43 ` [PATCH 09/17] riscv: provide a flat entry loader Christoph Hellwig 2019-06-24 5:43 ` [PATCH 10/17] riscv: read the hart ID from mhartid on boot Christoph Hellwig 2019-07-01 21:15 ` Atish Patra 2019-06-24 5:43 ` [PATCH 11/17] riscv: provide native clint access for M-mode Christoph Hellwig 2019-06-24 5:43 ` [PATCH 12/17] riscv: implement remote sfence.i natively " Christoph Hellwig 2019-06-24 5:43 ` [PATCH 13/17] riscv: poison SBI calls " Christoph Hellwig 2019-06-24 5:43 ` [PATCH 14/17] riscv: don't allow selecting SBI-based drivers " Christoph Hellwig 2019-06-24 5:43 ` [PATCH 15/17] riscv: use the correct interrupt levels " Christoph Hellwig 2019-06-24 5:43 ` [PATCH 16/17] riscv: clear the instruction cache and all registers when booting Christoph Hellwig 2019-07-01 21:26 ` Atish Patra 2019-07-08 8:26 ` Palmer Dabbelt 2019-08-13 15:40 ` Christoph Hellwig 2019-08-13 15:37 ` hch 2019-06-24 5:43 ` [PATCH 17/17] riscv: add nommu support Christoph Hellwig 2019-07-12 14:52 ` Vladimir Murzin 2019-06-24 11:47 ` RISC-V nommu support v2 Vladimir Murzin 2019-06-24 11:54 ` Christoph Hellwig 2019-06-24 13:08 ` Vladimir Murzin 2019-06-24 13:16 ` Christoph Hellwig 2019-06-25 7:31 ` Palmer Dabbelt [this message] 2019-06-25 12:37 ` Vladimir Murzin 2019-07-01 6:56 ` Christoph Hellwig 2019-07-01 16:06 ` Paul Walmsley
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=mhng-6f11ed95-e3f3-41dc-93c5-1576928b373b@palmer-si-x1e \ --to=palmer@sifive.com \ --cc=Damien.LeMoal@wdc.com \ --cc=hch@lst.de \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-riscv@lists.infradead.org \ --cc=paul.walmsley@sifive.com \ --cc=vladimir.murzin@arm.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
Linux-RISC-V Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-riscv/0 linux-riscv/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-riscv linux-riscv/ https://lore.kernel.org/linux-riscv \ linux-riscv@lists.infradead.org public-inbox-index linux-riscv Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.infradead.lists.linux-riscv AGPL code for this site: git clone https://public-inbox.org/public-inbox.git