On 25.04.2025 21:31, Oleksii Kurochko wrote:
>
> On 4/22/25 9:02 AM, Jan Beulich wrote:
>> On 18.04.2025 12:43, Oleksii Kurochko wrote:
>>> On 4/15/25 4:53 PM, Jan Beulich wrote:
>>>> On 08.04.2025 17:57, Oleksii Kurochko wrote:
>>>>> --- a/xen/arch/riscv/imsic.c
>>>>> +++ b/xen/arch/riscv/imsic.c
>>>>> @@ -14,12 +14,68 @@
>>>>> #include <xen/errno.h>
>>>>> #include <xen/init.h>
>>>>> #include <xen/macros.h>
>>>>> +#include <xen/spinlock.h>
>>>>> #include <xen/xmalloc.h>
>>>>>
>>>>> #include <asm/imsic.h>
>>>>>
>>>>> static struct imsic_config imsic_cfg;
>>>>>
>>>>> +#define imsic_csr_set(c, v) \
>>>>> +do { \
>>>>> + csr_write(CSR_SISELECT, c); \
>>>>> + csr_set(CSR_SIREG, v); \
>>>>> +} while (0)
>>>>> +
>>>>> +#define imsic_csr_clear(c, v) \
>>>>> +do { \
>>>>> + csr_write(CSR_SISELECT, c); \
>>>>> + csr_clear(CSR_SIREG, v); \
>>>>> +} while (0)
>>>> Coming back to these (the later patch adds one more here): How expensive
>>>> are
>>>> these CSR writes? IOW would it perhaps make sense to maintain a local cache
>>>> of the last written SISELECT value, to avoid writing the same one again if
>>>> the same windowed register needs accessing twice in a row?
>>> CSRs belong to the HART, so access to them is very fast.
>> Can you back this by any data? I view CSRs as somewhat similar to x86'es
>> MSRs,
>> and access (writes in particular) to some of them is rather slow.
>
> CSR read 1 cycle, CSR write 7 cycles on Microchip platform. ~ Oleksii
And that's an in-order platform, i.e. cycle count being all that matters for
performance? No other (e.g. latency) effect on subsequent insns?
Further, how does this compare to the outlined alternative, especially if we
assumed that the respective cacheline would be hot and hence usually in L1
cache?
Jan
