Received-SPF: pass (google.com: domain of linux-kernel+bounces-134985-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <ddc5555a-3ae8-42e5-a08a-ca5ceaf0bf28@rivosinc.com>
Date: Mon, 8 Apr 2024 10:01:12 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/5] Add parsing for Zimop ISA extension
To: Deepak Gupta <debug@rivosinc.com>, Andrew Jones <ajones@ventanamicro.com>
Cc: Jonathan Corbet <corbet@lwn.net>, Paul Walmsley
 <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>,
 Albert Ou <aou@eecs.berkeley.edu>, Conor Dooley <conor@kernel.org>,
 Rob Herring <robh@kernel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
 Anup Patel <anup@brainfault.org>, Shuah Khan <shuah@kernel.org>,
 Atish Patra <atishp@atishpatra.org>, linux-doc@vger.kernel.org,
 linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
 devicetree@vger.kernel.org, kvm@vger.kernel.org,
 kvm-riscv@lists.infradead.org, linux-kselftest@vger.kernel.org
References: <20240404103254.1752834-1-cleger@rivosinc.com>
 <20240405-091c6c174f023d74b434059d@orel>
 <CAKC1njQ3qQ8mTMoYkhhoGQfRSVtp2Tfd2LjDhAmut7UcW9-bGw@mail.gmail.com>
Content-Language: en-US
From: =?UTF-8?B?Q2zDqW1lbnQgTMOpZ2Vy?= <cleger@rivosinc.com>
In-Reply-To: <CAKC1njQ3qQ8mTMoYkhhoGQfRSVtp2Tfd2LjDhAmut7UcW9-bGw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit


On 05/04/2024 19:33, Deepak Gupta wrote:
> On Fri, Apr 5, 2024 at 8:26 AM Andrew Jones <ajones@ventanamicro.com> wrote:
>>
>> On Thu, Apr 04, 2024 at 12:32:46PM +0200, Clément Léger wrote:
>>> The Zimop ISA extension was ratified recently. This series adds support
>>> for parsing it from riscv,isa, hwprobe export and kvm support for
>>> Guest/VM.
>>
>> I'm not sure we need this. Zimop by itself isn't useful, so I don't know
>> if we need to advertise it at all. When an extension comes along that
>> redefines some MOPs, then we'll advertise that extension, but the fact
>> Zimop is used for that extension is really just an implementation detail.
> 
> Only situation I see this can be useful is this:--
> 
> An implementer, implemented Zimops in CPU solely for the purpose that they can
> run mainline distro & packages on their hardware and don't want to leverage any
> feature which are built on top of Zimop.

Yes, the rationale was that some binaries using extensions that overload
MOPs could still be run. With Zimop exposed, the loader could determine
if the binary can be executed without potentially crashing. We could
also let the program run anyway but the execution could potentially
crash unexpectedly, which IMHO is not really good for the user
experience nor for debugging. I already think that the segfaults which
happens when executing binaries that need some missing extension are not
so easy to debug, so better add more guards.

> 
> As an example zicfilp and zicfiss are dependent on zimops. glibc can
> do following
> 
> 1) check elf header if binary was compiled with zicfiss and zicfilp,
> if yes goto step 2, else goto step 6.
> 2) check if zicfiss/zicfilp is available in hw via hwprobe, if yes
> goto step 5. else goto step 3
> 3) check if zimop is available via hwprobe, if yes goto step 6, else goto step 4

I think you meant step 5 rather than step 6.

Clément

> 4) This binary won't be able to run successfully on this platform,
> issue exit syscall. <-- termination
> 5) issue prctl to enable shadow stack and landing pad for current task
> <-- enable feature
> 6) let the binary run <-- let the binary run because no harm can be done