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

On 5/13/26 09:04, Anup Patel wrote:
> 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

Thanks Anup, understood and shall amend it as per your suggestion above.

Thanks
Dave

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