public inbox for opensbi@lists.infradead.org
 help / color / mirror / Atom feed
From: cp0613@linux.alibaba.com
To: rkrcmar@ventanamicro.com
Cc: anup@brainfault.org, guoren@kernel.org, opensbi@lists.infradead.org
Subject: Re: [PATCH v3] lib: sbi: Enable Ssqosid Ext using mstateen0
Date: Tue, 11 Nov 2025 17:49:36 +0800	[thread overview]
Message-ID: <20251111094938.1492-1-cp0613@linux.alibaba.com> (raw)
In-Reply-To: <DE53DAU3LAAK.2FGKTU66OSUEX@ventanamicro.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

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

  reply	other threads:[~2025-11-11  9:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-07  8:32 [PATCH v3] lib: sbi: Enable Ssqosid Ext using mstateen0 cp0613
2025-11-07 11:13 ` Radim Krčmář
2025-11-08 11:22   ` cp0613
2025-11-10  8:32     ` Radim Krčmář
2025-11-10 12:31       ` cp0613
2025-11-10 14:41         ` Radim Krčmář
2025-11-11  9:49           ` cp0613 [this message]
2025-11-11 10:18             ` Radim Krčmář

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251111094938.1492-1-cp0613@linux.alibaba.com \
    --to=cp0613@linux.alibaba.com \
    --cc=anup@brainfault.org \
    --cc=guoren@kernel.org \
    --cc=opensbi@lists.infradead.org \
    --cc=rkrcmar@ventanamicro.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox