[PATCH v3] lib: sbi: Enable Ssqosid Ext using mstateen0

[cp0613 at linux.alibaba.com]

On 2025-11-10 02:41 PM, Radim Krčmář wrote:

>> I think it's because srmcfg has effect on M-mode, so the extension is
>> completely independent to allow it in pure M systems.
>> 
>> (We enable srmcfg in mstateen regardless of S version, so there is a
>>  potential bug where we wouldn't correctly context switch the csr, given
>>  a system with weird combination of extensions.)

> We might have taked past each other here.
> 
> I'm arguing that RISC-V allows a hart with ISA S1p11_Ssqosid to exist,
> because Ssqosid doesn't depend on S, so opensbi should context switch
> srmcfg on such potential (albeit unlikely) machine.
> 
> Otherwise domains could observe srmcfg set by other domains.
> 
> > I have a different opinion on this point. This extension is basically unrelated
> > to M-mode, instead, it runs in S-mode. It may be necessary to consider the background
> > of ssqosid's introduction. This is to ensure that certain critical business processes
> > can obtain sufficient hardware resources to run and thus guarantee service quality.
> >
> > Similar technologies include Intel-RDT and ARM MPAM. On the Linux side, Drew has already
> > submitted relevant patches [1]. It can be seen that in the future, it will inevitably be
> > used in conjunction with Linux resctrl,
> 
> Yeah, I'm planning to look at the patches as well, because Ssqosid's
> design has a lot of potential for side-channels.
> 
> >                                         so there is no need to consider the execution
> > situation in M-mode, it is only necessary to enable the relevant permissions.
> 
> The execution of M-mode is affected by srmcfg, so we have to be
> extremely careful about isolation in opensbi too, especially when
> juggling multiple domains.
> 
> (I think we might be fine now, but having opensbi switch to a srmcfg
>  that isn't controlled by S-mode will result in a lot less headaches...)
> 
> Thanks.

Indeed, strictly speaking, the execution of M-mode is also affected by srmcfg.
When dealing with multiple domains, attention needs to be paid to isolation and
context switching issues. I understand your point of view.

However, I wonder if it could be done in a later stage of the work, because there
is currently a draft specification smmtt[1] that is also related to this. This
extension involves multiple Supervisor Domains, and at this time, it is necessary
to implement context switching of srmcfg between different domains.

Thanks,
Pei

[1] https://github.com/riscv/riscv-smmtt