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

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

[cp0613]

From: Chen Pei <cp0613@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@linux.alibaba.com>
---
 include/sbi/riscv_encoding.h | 5 +++++
 include/sbi/sbi_hart.h       | 2 ++
 lib/sbi/sbi_domain_context.c | 4 ++++
 lib/sbi/sbi_hart.c           | 6 ++++++
 4 files changed, 17 insertions(+)

diff --git a/include/sbi/riscv_encoding.h b/include/sbi/riscv_encoding.h
index 61e4b635..b738e209 100644
--- a/include/sbi/riscv_encoding.h
+++ b/include/sbi/riscv_encoding.h
@@ -378,6 +378,9 @@
 #define CSR_SSTATEEN2			0x10E
 #define CSR_SSTATEEN3			0x10F
 
+/* Supervisor Resource Management Configuration CSRs */
+#define CSR_SRMCFG			0x181
+
 /* Machine-Level Control transfer records CSRs */
 #define CSR_MCTRCTL                     0x34e
 
@@ -849,6 +852,8 @@
 #define SMSTATEEN0_FCSR			(_ULL(1) << SMSTATEEN0_FCSR_SHIFT)
 #define SMSTATEEN0_CTR_SHIFT		54
 #define SMSTATEEN0_CTR			(_ULL(1) << SMSTATEEN0_CTR_SHIFT)
+#define SMSTATEEN0_SRMCFG_SHIFT		55
+#define SMSTATEEN0_SRMCFG		(_ULL(1) << SMSTATEEN0_SRMCFG_SHIFT)
 #define SMSTATEEN0_CONTEXT_SHIFT	57
 #define SMSTATEEN0_CONTEXT		(_ULL(1) << SMSTATEEN0_CONTEXT_SHIFT)
 #define SMSTATEEN0_IMSIC_SHIFT		58
diff --git a/include/sbi/sbi_hart.h b/include/sbi/sbi_hart.h
index e66dd52f..c51b0689 100644
--- a/include/sbi/sbi_hart.h
+++ b/include/sbi/sbi_hart.h
@@ -79,6 +79,8 @@ enum sbi_hart_extensions {
 	SBI_HART_EXT_SMCTR,
 	/** HART has CTR S-mode CSRs */
 	SBI_HART_EXT_SSCTR,
+	/** Hart has Ssqosid extension */
+	SBI_HART_EXT_SSQOSID,
 	/** HART has Ssstateen extension **/
 	SBI_HART_EXT_SSSTATEEN,
 	/** Hart has Xsfcflushdlone extension */
diff --git a/lib/sbi/sbi_domain_context.c b/lib/sbi/sbi_domain_context.c
index 74ad25e8..a66438e4 100644
--- a/lib/sbi/sbi_domain_context.c
+++ b/lib/sbi/sbi_domain_context.c
@@ -45,6 +45,8 @@ struct hart_context {
 	unsigned long scounteren;
 	/** Supervisor environment configuration register */
 	unsigned long senvcfg;
+	/** Supervisor resource management configuration register */
+	unsigned long srmcfg;
 
 	/** Reference to the owning domain */
 	struct sbi_domain *dom;
@@ -145,6 +147,8 @@ static int switch_to_next_domain_context(struct hart_context *ctx,
 		ctx->scounteren = csr_swap(CSR_SCOUNTEREN, dom_ctx->scounteren);
 	if (sbi_hart_priv_version(scratch) >= SBI_HART_PRIV_VER_1_12)
 		ctx->senvcfg	= csr_swap(CSR_SENVCFG, dom_ctx->senvcfg);
+	if (sbi_hart_has_extension(scratch, SBI_HART_EXT_SSQOSID))
+		ctx->srmcfg	= csr_swap(CSR_SRMCFG, dom_ctx->srmcfg);
 
 	/* Save current trap state and restore target domain's trap state */
 	trap_ctx = sbi_trap_get_context(scratch);
diff --git a/lib/sbi/sbi_hart.c b/lib/sbi/sbi_hart.c
index a91703b4..295a6783 100644
--- a/lib/sbi/sbi_hart.c
+++ b/lib/sbi/sbi_hart.c
@@ -112,6 +112,11 @@ static void mstatus_init(struct sbi_scratch *scratch)
 		else
 			mstateen_val &= ~SMSTATEEN0_CTR;
 
+		if (sbi_hart_has_extension(scratch, SBI_HART_EXT_SSQOSID))
+			mstateen_val |= SMSTATEEN0_SRMCFG;
+		else
+			mstateen_val &= ~SMSTATEEN0_SRMCFG;
+
 		csr_write64(CSR_MSTATEEN0, mstateen_val);
 		csr_write64(CSR_MSTATEEN1, SMSTATEEN_STATEN);
 		csr_write64(CSR_MSTATEEN2, SMSTATEEN_STATEN);
@@ -685,6 +690,7 @@ const struct sbi_hart_ext_data sbi_hart_ext[] = {
 	__SBI_HART_EXT_DATA(ssdbltrp, SBI_HART_EXT_SSDBLTRP),
 	__SBI_HART_EXT_DATA(smctr, SBI_HART_EXT_SMCTR),
 	__SBI_HART_EXT_DATA(ssctr, SBI_HART_EXT_SSCTR),
+	__SBI_HART_EXT_DATA(ssqosid, SBI_HART_EXT_SSQOSID),
 	__SBI_HART_EXT_DATA(ssstateen, SBI_HART_EXT_SSSTATEEN),
 	__SBI_HART_EXT_DATA(xsfcflushdlone, SBI_HART_EXT_XSIFIVE_CFLUSH_D_L1),
 	__SBI_HART_EXT_DATA(xsfcease, SBI_HART_EXT_XSIFIVE_CEASE),
-- 
2.50.1


-- 
opensbi mailing list
opensbi@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/opensbi

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

[Radim Krčmář]

2025-11-14T19:57:22+08:00, <cp0613@linux.alibaba.com>:
> From: Chen Pei <cp0613@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@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,

Reviewed-by: Radim Krčmář <rkrcmar@ventanamicro.com>

Thanks.

-- 
opensbi mailing list
opensbi@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/opensbi

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

[Guo Ren]

On Fri, Nov 14, 2025 at 9:55 PM Radim Krčmář <rkrcmar@ventanamicro.com> wrote:
>
> 2025-11-14T19:57:22+08:00, <cp0613@linux.alibaba.com>:
> > From: Chen Pei <cp0613@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@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.

Compared to switching the srmcfg, I prefer to enable SMSTATEEN0_SRMCFG
only in one domain (the default one).

-- 
Best Regards
 Guo Ren

-- 
opensbi mailing list
opensbi@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/opensbi

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

[Guo Ren]

On Sat, Nov 15, 2025 at 11:05 AM Guo Ren <guoren@kernel.org> wrote:
>
> On Fri, Nov 14, 2025 at 9:55 PM Radim Krčmář <rkrcmar@ventanamicro.com> wrote:
> >
> > 2025-11-14T19:57:22+08:00, <cp0613@linux.alibaba.com>:
> > > From: Chen Pei <cp0613@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@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.
>
> Compared to switching the srmcfg, I prefer to enable SMSTATEEN0_SRMCFG
> only in one domain (the default one).
Leaving it away is more considerable.

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.

>
> --
> Best Regards
>  Guo Ren



-- 
Best Regards
 Guo Ren

-- 
opensbi mailing list
opensbi@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/opensbi

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

[Radim Krčmář]

2025-11-15T11:17:52+08:00, Guo Ren <guoren@kernel.org>:
> On Sat, Nov 15, 2025 at 11:05 AM Guo Ren <guoren@kernel.org> wrote:
>>
>> On Fri, Nov 14, 2025 at 9:55 PM Radim Krčmář <rkrcmar@ventanamicro.com> wrote:
>> >
>> > 2025-11-14T19:57:22+08:00, <cp0613@linux.alibaba.com>:
>> > > From: Chen Pei <cp0613@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@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.

-- 
opensbi mailing list
opensbi@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/opensbi

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

[Guo Ren]

On Tue, Nov 18, 2025 at 10:03 PM Radim Krčmář <rkrcmar@ventanamicro.com> wrote:
>
> 2025-11-15T11:17:52+08:00, Guo Ren <guoren@kernel.org>:
> > On Sat, Nov 15, 2025 at 11:05 AM Guo Ren <guoren@kernel.org> wrote:
> >>
> >> On Fri, Nov 14, 2025 at 9:55 PM Radim Krčmář <rkrcmar@ventanamicro.com> wrote:
> >> >
> >> > 2025-11-14T19:57:22+08:00, <cp0613@linux.alibaba.com>:
> >> > > From: Chen Pei <cp0613@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@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?
I recommend removing the switch_to_next_domain_context modification in
this patch, because the solution is not ready. We could leave it for a
later comprehensive solution (e.g., TSM).

When we set srmcfg on the Linux side via the resctrl interface and
create a TVM using the CoVE API, the qosid setting is naturally
inherited by the TVM, which is what I expect: let the lowest-privilege
domain set up srmcfg. This patch's srmcfg switch in
switch_to_next_domain_context breaks the path.

>
> Thanks.



-- 
Best Regards
 Guo Ren

-- 
opensbi mailing list
opensbi@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/opensbi

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

[Anup Patel]

On Wed, Nov 19, 2025 at 7:44 AM Guo Ren <guoren@kernel.org> wrote:
>
> On Tue, Nov 18, 2025 at 10:03 PM Radim Krčmář <rkrcmar@ventanamicro.com> wrote:
> >
> > 2025-11-15T11:17:52+08:00, Guo Ren <guoren@kernel.org>:
> > > On Sat, Nov 15, 2025 at 11:05 AM Guo Ren <guoren@kernel.org> wrote:
> > >>
> > >> On Fri, Nov 14, 2025 at 9:55 PM Radim Krčmář <rkrcmar@ventanamicro.com> wrote:
> > >> >
> > >> > 2025-11-14T19:57:22+08:00, <cp0613@linux.alibaba.com>:
> > >> > > From: Chen Pei <cp0613@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@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?
> I recommend removing the switch_to_next_domain_context modification in
> this patch, because the solution is not ready. We could leave it for a
> later comprehensive solution (e.g., TSM).

If we leave out the switch_to_next_domain_context () change then
there is side-channel being exposed for inter-domain communication
which we don't want.

>
> When we set srmcfg on the Linux side via the resctrl interface and
> create a TVM using the CoVE API, the qosid setting is naturally
> inherited by the TVM, which is what I expect: let the lowest-privilege
> domain set up srmcfg. This patch's srmcfg switch in
> switch_to_next_domain_context breaks the path.

The switch_to_next_domain_context () is doing its job correctly
but the real issue is the lack of separation of RCID and MCID
space between domains.

Trap-n-emulation of srmcfg CSR for S-mode will impact performance
because S-mode OSes might switch RCID and MCID in task-switch.
Ideally, we should have separate ISA extension for M-mode to
isolate RCID and MCID space between domains.

For now, let's go ahead with this patch and separately we can
think about inter-domain isolation of RCID and MCID space.

Regards,
Anup

-- 
opensbi mailing list
opensbi@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/opensbi

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

[Anup Patel]

On Fri, Nov 14, 2025 at 5:27 PM <cp0613@linux.alibaba.com> wrote:
>
> From: Chen Pei <cp0613@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@linux.alibaba.com>

Applied this patch to the riscv/opensbi repo.

Thanks,
Anup


> ---
>  include/sbi/riscv_encoding.h | 5 +++++
>  include/sbi/sbi_hart.h       | 2 ++
>  lib/sbi/sbi_domain_context.c | 4 ++++
>  lib/sbi/sbi_hart.c           | 6 ++++++
>  4 files changed, 17 insertions(+)
>
> diff --git a/include/sbi/riscv_encoding.h b/include/sbi/riscv_encoding.h
> index 61e4b635..b738e209 100644
> --- a/include/sbi/riscv_encoding.h
> +++ b/include/sbi/riscv_encoding.h
> @@ -378,6 +378,9 @@
>  #define CSR_SSTATEEN2                  0x10E
>  #define CSR_SSTATEEN3                  0x10F
>
> +/* Supervisor Resource Management Configuration CSRs */
> +#define CSR_SRMCFG                     0x181
> +
>  /* Machine-Level Control transfer records CSRs */
>  #define CSR_MCTRCTL                     0x34e
>
> @@ -849,6 +852,8 @@
>  #define SMSTATEEN0_FCSR                        (_ULL(1) << SMSTATEEN0_FCSR_SHIFT)
>  #define SMSTATEEN0_CTR_SHIFT           54
>  #define SMSTATEEN0_CTR                 (_ULL(1) << SMSTATEEN0_CTR_SHIFT)
> +#define SMSTATEEN0_SRMCFG_SHIFT                55
> +#define SMSTATEEN0_SRMCFG              (_ULL(1) << SMSTATEEN0_SRMCFG_SHIFT)
>  #define SMSTATEEN0_CONTEXT_SHIFT       57
>  #define SMSTATEEN0_CONTEXT             (_ULL(1) << SMSTATEEN0_CONTEXT_SHIFT)
>  #define SMSTATEEN0_IMSIC_SHIFT         58
> diff --git a/include/sbi/sbi_hart.h b/include/sbi/sbi_hart.h
> index e66dd52f..c51b0689 100644
> --- a/include/sbi/sbi_hart.h
> +++ b/include/sbi/sbi_hart.h
> @@ -79,6 +79,8 @@ enum sbi_hart_extensions {
>         SBI_HART_EXT_SMCTR,
>         /** HART has CTR S-mode CSRs */
>         SBI_HART_EXT_SSCTR,
> +       /** Hart has Ssqosid extension */
> +       SBI_HART_EXT_SSQOSID,
>         /** HART has Ssstateen extension **/
>         SBI_HART_EXT_SSSTATEEN,
>         /** Hart has Xsfcflushdlone extension */
> diff --git a/lib/sbi/sbi_domain_context.c b/lib/sbi/sbi_domain_context.c
> index 74ad25e8..a66438e4 100644
> --- a/lib/sbi/sbi_domain_context.c
> +++ b/lib/sbi/sbi_domain_context.c
> @@ -45,6 +45,8 @@ struct hart_context {
>         unsigned long scounteren;
>         /** Supervisor environment configuration register */
>         unsigned long senvcfg;
> +       /** Supervisor resource management configuration register */
> +       unsigned long srmcfg;
>
>         /** Reference to the owning domain */
>         struct sbi_domain *dom;
> @@ -145,6 +147,8 @@ static int switch_to_next_domain_context(struct hart_context *ctx,
>                 ctx->scounteren = csr_swap(CSR_SCOUNTEREN, dom_ctx->scounteren);
>         if (sbi_hart_priv_version(scratch) >= SBI_HART_PRIV_VER_1_12)
>                 ctx->senvcfg    = csr_swap(CSR_SENVCFG, dom_ctx->senvcfg);
> +       if (sbi_hart_has_extension(scratch, SBI_HART_EXT_SSQOSID))
> +               ctx->srmcfg     = csr_swap(CSR_SRMCFG, dom_ctx->srmcfg);
>
>         /* Save current trap state and restore target domain's trap state */
>         trap_ctx = sbi_trap_get_context(scratch);
> diff --git a/lib/sbi/sbi_hart.c b/lib/sbi/sbi_hart.c
> index a91703b4..295a6783 100644
> --- a/lib/sbi/sbi_hart.c
> +++ b/lib/sbi/sbi_hart.c
> @@ -112,6 +112,11 @@ static void mstatus_init(struct sbi_scratch *scratch)
>                 else
>                         mstateen_val &= ~SMSTATEEN0_CTR;
>
> +               if (sbi_hart_has_extension(scratch, SBI_HART_EXT_SSQOSID))
> +                       mstateen_val |= SMSTATEEN0_SRMCFG;
> +               else
> +                       mstateen_val &= ~SMSTATEEN0_SRMCFG;
> +
>                 csr_write64(CSR_MSTATEEN0, mstateen_val);
>                 csr_write64(CSR_MSTATEEN1, SMSTATEEN_STATEN);
>                 csr_write64(CSR_MSTATEEN2, SMSTATEEN_STATEN);
> @@ -685,6 +690,7 @@ const struct sbi_hart_ext_data sbi_hart_ext[] = {
>         __SBI_HART_EXT_DATA(ssdbltrp, SBI_HART_EXT_SSDBLTRP),
>         __SBI_HART_EXT_DATA(smctr, SBI_HART_EXT_SMCTR),
>         __SBI_HART_EXT_DATA(ssctr, SBI_HART_EXT_SSCTR),
> +       __SBI_HART_EXT_DATA(ssqosid, SBI_HART_EXT_SSQOSID),
>         __SBI_HART_EXT_DATA(ssstateen, SBI_HART_EXT_SSSTATEEN),
>         __SBI_HART_EXT_DATA(xsfcflushdlone, SBI_HART_EXT_XSIFIVE_CFLUSH_D_L1),
>         __SBI_HART_EXT_DATA(xsfcease, SBI_HART_EXT_XSIFIVE_CEASE),
> --
> 2.50.1
>

-- 
opensbi mailing list
opensbi@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/opensbi