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

[Radim Krčmář]

2025-11-15T11:17:52+08:00, Guo Ren <guoren at kernel.org>:
> On Sat, Nov 15, 2025 at 11:05 AM Guo Ren <guoren at kernel.org> wrote:
>>
>> On Fri, Nov 14, 2025 at 9:55 PM Radim Krčmář <rkrcmar at ventanamicro.com> wrote:
>> >
>> > 2025-11-14T19:57:22+08:00, <cp0613 at linux.alibaba.com>:
>> > > From: Chen Pei <cp0613 at linux.alibaba.com>
>> > >
>> > > The QoS Identifiers extension (Ssqosid) introduces the srmcfg register,
>> > > which configures a hart with two identifiers: a Resource Control ID
>> > > (RCID) and a Monitoring Counter ID (MCID). These identifiers accompany
>> > > each request issued by the hart to shared resource controllers.
>> > >
>> > > If extension Smstateen is implemented together with Ssqosid, then
>> > > Ssqosid also requires the SRMCFG bit in mstateen0 to be implemented. If
>> > > mstateen0.SRMCFG is 0, attempts to access srmcfg in privilege modes less
>> > > privileged than M-mode raise an illegal-instruction exception. If
>> > > mstateen0.SRMCFG is 1 or if extension Smstateen is not implemented,
>> > > attempts to access srmcfg when V=1 raise a virtual-instruction exception.
>> > >
>> > > This extension can be found in the RISC-V Instruction Set Manual:
>> > > https://github.com/riscv/riscv-isa-manual
>> > >
>> > > Changes in v5:
>> > >  - Remove SBI_HART_EXT_SSQOSID dependency SBI_HART_PRIV_VER_1_12
>> > >
>> > > Changes in v4:
>> > >  - Remove extraneous parentheses around SMSTATEEN0_SRMCFG
>> > >
>> > > Changes in v3:
>> > >  - Check SBI_HART_EXT_SSQOSID when swapping SRMCFG
>> > >
>> > > Changes in v2:
>> > >  - Remove trap-n-detect
>> > >  - Context switch CSR_SRMCFG
>> > >
>> > > Signed-off-by: Chen Pei <cp0613 at linux.alibaba.com>
>> > > ---
>> >
>> > It's possible that S-mode control over srmcfg might leak very little
>> > information across architectural isolation boundaries, but I don't know
>> > enough about CBQRI to mount any practical attack (it might not exist),
>> > so the current handling seems acceptable,
>> For multiple domains, the srmcfg(QoS ID Pool) must be managed globally
>> in m-mode, or domain A would affect domain B by using its own srmcfg.

Right, vendors shouldn't add Ssqosid to the ISA string unless they know
what they are doing.
i.e. allowing no more than single domain that runs uncontrolled code,
and configuring srmcfg in their controlled domains to be unconstrained.

When we have SmMTT's mnrmcfg, I imagine vendors will be able to start
using srmcfg inside service domains, or even allow multiple user
domains.  (We'll need extra management in opensbi for it, though.)

>> Compared to switching the srmcfg, I prefer to enable SMSTATEEN0_SRMCFG
>> only in one domain (the default one).
>
> Leaving it away is more considerable.

You mean trapping to opensbi and implementing filtering akin to SmMTT?

> Think about the CoVE scenario: Domain A (KVM) sets up QoS_ID, then
> Domain B (TVM) uses the QoS_ID from Domain A. Thus, TVM lets regular
> Linux KVM manage the QoS_ID & CBQRI.

CoVE currently has no option to set srmcfg for a TVM -- TSM should
currently set srmcfg to unconstrained, and this patch will
context-switch it without losing too much (any?) confidentiality.

I think this patch is fine if used correctly, but it definitely widens
room for errors.  Do we want to somehow increase the robustness?

Thanks.