[PATCH v4 2/6] RISC-V: Enable cbo.zero in usermode

[Andrew Jones]

On Thu, Sep 21, 2023 at 07:52:10PM +0530, Anup Patel wrote:
> On Thu, Sep 21, 2023 at 7:00 PM Palmer Dabbelt <palmer at dabbelt.com> wrote:
> >
> > On Mon, 18 Sep 2023 06:15:21 PDT (-0700), ajones at ventanamicro.com wrote:
...
> > > +void riscv_user_isa_enable(void)
> > > +{
> > > +     if (riscv_cpu_has_extension_unlikely(smp_processor_id(), RISCV_ISA_EXT_ZICBOZ))
> > > +             csr_set(CSR_SENVCFG, ENVCFG_CBZE);
> >
> > It looks like CBZE didn't actually get ratified?  The CMO extension says
> >
> >     _The CMO extensions rely on state in {csrname} CSRs that will be defined in a
> >     future update to the privileged architecture. If this CSR update is not
> >     ratified, the CMO extension will define its own CSRs._
> >
> > but the privileged spec says
> >
> >     The definition of the CBZE field will be furnished by the forthcoming
> >     Zicboz extension. Its allocation within `senvcfg` may change prior to
> >     the ratification of that extension.
> >
> > Is there some ratified spec that actually defines this?
> 
> I see what you mean. The integration of these bits into the RISC-V
> priv spec has not happened hence we have the non-normative text
> in the CMO specification. The bit positions in xenvcfg CSRs can't
> change because it's already part of ratified CMO specification and
> there are organizations (like Ventana) who have implemented these
> bits.
> 

Hi Palmer,

Does Anup's response satisfy the criteria for this? I'm wondering what, if
anything, I should do with this series. (The hwprobe-which-cpus series
is currently based on this series, because of the hwprobe selftests
changes, but I guess I could rework that.)

Thanks,
drew