Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp2482735ybd; Mon, 24 Jun 2019 07:12:41 -0700 (PDT) X-Google-Smtp-Source: APXvYqwIH/Uth8Tkswt4wFPuHiC/pUhQoPRwKWcLXRmYa9He/eVtI8a9mqGhfy4H6mEq6IG5HM6A X-Received: by 2002:a63:1723:: with SMTP id x35mr28353256pgl.233.1561385561427; Mon, 24 Jun 2019 07:12:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561385561; cv=none; d=google.com; s=arc-20160816; b=pdtafUERrkpxfnotcT4+2sEDvpR+JyDB6A5DZn0Akhz4AK974GtodyXga5e7R2bVYL Fr5+YrqzQl3CGyIpi2/KqJTPL/pgvM1RBSSQsC47r+fBvQHtdifQGY0lf4PNsS+7d/Gp zk37uAGzucowOQuYvCE0vwpveqf6KV14qFI48sIGsCKE2KPi3rHjHCXUmVC+N2Hw5Ynd Ue1Mqyn1gvf6Kgmj6JjN7c1TlHOKqZ7aOhG9QwWb5G/E+ckySnVisSQUwgzZXx2ywZZA Kytg23hg9p8IXcYp2LHiU+2vn9Wwe+UEUiKn8rEollGQZSeLko5lDvFarwhXjx8X15Ku hcNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=1eYipjag048mHuiA7OAV4PsGwY6OaH3lXVSFrCq2e/g=; b=S5HOrOzuTxvIoxg01TosXEeckr1V2/nZTtrDzgG2re1EY9ozbPPnCH4s65zdjnqb0X HFzSeStuxXv9xRuspsFamI/XAlf+vxzKp6A97Yf4/qkGhRL5WKiR2qzQsBvNptyJwwrs GookUTyAhArYDz5A6v2Qw7ZxiXAXSDfRISJOO6bIn53WcdNrYvGOPj0NeC7iGRkKu3Km 9+8Y490AwuZepCE1umG0y7tt5rk1+VUYdyInvd9KPYykiPPAwDXmfF0eh703iaPmcGV3 cCvvcmBnXtHZ5cpOv4n4BLDJw7ZZFUTS33IzgKnO+yeVFrURbwGuuQNnQWif+5fJepDa nDpQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f17si10198594pgv.338.2019.06.24.07.12.26; Mon, 24 Jun 2019 07:12:41 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730687AbfFXNIy (ORCPT + 99 others); Mon, 24 Jun 2019 09:08:54 -0400 Received: from foss.arm.com ([217.140.110.172]:49804 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727065AbfFXNIx (ORCPT ); Mon, 24 Jun 2019 09:08:53 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4D4FD344; Mon, 24 Jun 2019 06:08:53 -0700 (PDT) Received: from [10.1.32.158] (unknown [10.1.32.158]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BB6A33F71E; Mon, 24 Jun 2019 06:08:51 -0700 (PDT) Subject: Re: RISC-V nommu support v2 To: Christoph Hellwig Cc: Palmer Dabbelt , Paul Walmsley , Damien Le Moal , linux-riscv@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20190624054311.30256-1-hch@lst.de> <28e3d823-7b78-fa2b-5ca7-79f0c62f9ecb@arm.com> <20190624115428.GA9538@lst.de> From: Vladimir Murzin Message-ID: Date: Mon, 24 Jun 2019 14:08:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20190624115428.GA9538@lst.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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