Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   =?ISO-8859-1?Q?R=E9mi?= Denis-Courmont <remi@remlab.net>
To:     linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Cc:     andy.chiu@sifive.com, Palmer Dabbelt <palmer@dabbelt.com>
Subject: Re: [PATCH -next v20 20/26] riscv: Add prctl controls for userspace vector
 management
Date:   Wed, 24 May 2023 19:13:10 +0300
Message-ID: <2621691.14T4csFsIl@basile.remlab.net>
Organization: Remlab
In-Reply-To: <mhng-52f8af07-f3fc-4674-94ea-abbe2108907a@palmer-ri-x1c9a>
References: <mhng-52f8af07-f3fc-4674-94ea-abbe2108907a@palmer-ri-x1c9a>
MIME-Version: 1.0
Content-Transfer-Encoding: 8BIT
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Le keskiviikkona 24. toukokuuta 2023, 3.18.26 EEST Palmer Dabbelt a écrit :
> > I don't think the value of an auxillary vector entry can change in an
> > existing process nor that we need that. If an application starts with V
> > disabled, you can keep the V bit clear even if V gets enabled later on;
> > that won't break existing userspace code, which simply won't use vectors.
> > 
> > What does break existing userspace is setting the V bit whilst vectors are
> > disabled.
> So maybe the right answer is to just not set V at all?

That is one possibility that I can live, although it feels unnecessarily user-
hostile compared to setting it only if the process _started_ with V enabled.

> The
> single-letter extensions are sort of defunct now, there's multi-letter
> sub extensions for most things, but V got ratified with those
> sub-extensions so we could just call it extra-ambiguous?

Maybe; I must admit I have zero visibility to RVI inner workings. At least C, 
D and F bits could work for JIT use cases, I suppose. E and M are totally 
impractical to support. G, I, X and Z cannot are already wasted by the design, 
and I guess we will now waste all 16 others.

But as for V, what is the user-space story for the prctl()? Who is intended to 
enablet V mode? If there is no clear story, it is all but guaranteed that 
random libraries will call it, and just _blindly_ assume that there is enough 
stack space for signal handling. If so, then there is not much point having a 
prctl() in the first place; might as well stick to just a kernel Kconfig with no 
runtime configuration.

-- 
Rémi Denis-Courmont
http://www.remlab.net/