Re: [PATCH v4 0/3] Add eager FP and RISC-V vector context switching support

On Wed, May 13, 2026 at 1:28 PM Dave Patel <[email protected]> wrote:
>
> On 5/13/26 08:42, Anup Patel wrote:
> > On Wed, May 13, 2026 at 12:44 PM <[email protected]> wrote:
> >>
> >> Hi Anup,
> >>         Thank you for taking out time and reviewing the patches.
> >> Following your review comments, I have made following changes. Also I have
> >> tested the changes.
> >>
> >> The changes include:
> >>         - Dropping CONFIG_SBI_MAX_VLENB and sbi_vector_domain_init()
> >>         - struct sbi_vector_context vec_ctx is now struct * in
> >>           'struct hart_context'
> >>         - changing READ_CSR and WRITE_CSR to vcsr_read and vcsr_write
> >
> > I think you misunderstood my previous comment. We already
> > have csr_read() and csr_write() defined in riscv_asm.h so use
> > these macros instead of introducing  vcsr_read() and vcsr_write().
> >
> >>
> >> I have covered all your comments, please can you have a look and let me know.
> >>
> >
> > Regards,
> > Anup
>
> Hi Anup,
>         Thanks,
>
> There is subtle difference between csr_read/write and vcsr_read/write in
> the context that this explicitly enables and isolates the RISC-V Vector
> (V) extension during compilation. This allows the program to read
> vector-specific Control and Status Registers (such as vlenb, vl, or
> vtype) without requiring the entire project to be compiled with global
> vector support.

I totally disagree. Your vcsr_read() is exactly same as csr_read()
except that it relies on compiler nemomics instead of CSR number.

>
> Vector Architecture Override: The directive .option arch, +v dynamically
> tells the assembler that the Vector extension is supported for this
> specific instruction block. A standard csr_read lacks this, causing
> compilation to fail if vector registers are accessed without global
> -march vector flags.
> Context Protection: The .option push and .option pop directives
> safeguard the build environment. They save the original compiler
> options, temporarily inject the vector extension, and immediately
> restore the original settings so subsequent code is unaffected.
> Memory Serialization: The inclusion of the "memory" clobber acts as a
> optimization barrier. It prevents the compiler from reordering memory
> reads or writes around the CSR operation, which is critical for vector
> state updates.
>
> So should I update it to normal csr_read/write instead?

Older toolchains dont understand vector nemonics that
is why I insist on using common csr_read/write().

Regards,
Anup

-- 
opensbi mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/opensbi