From: Xiang W <wxjstz@126.com>
To: opensbi@lists.infradead.org
Subject: [PATCH] sbi: fwft: clear the config lock when warm boot
Date: Fri, 22 Nov 2024 12:06:03 +0800 [thread overview]
Message-ID: <18291f649c4da495a0fdb0fde704c8bb536c7dad.camel@126.com> (raw)
In-Reply-To: <eed46dd5-d9d1-4ab7-86a1-ee74747d4310@sifive.com>
? 2024-11-21?? 21:24 -0600?Samuel Holland???
> Hi Xiang,
>
> On 2024-11-21 8:45 PM, Xiang W wrote:
> > ? 2024-11-15?? 15:33 +0800?Nick Hu???
> > > The hotplug cpu should clear the fwft config's SBI_FWFT_SET_FLAG_LOCK
> > > in the warm boot flow otherwise the cpu can't set the menvcfg.sse by
> > > SBI_EXT_FWFT_SET sbi call and cause the illegal instruction when
> > > accessing the CSR_SSP in kernel.
> > >
> > > Signed-off-by: Nick Hu <nick.hu@sifive.com>
> >
> > In sbi_fwft_init, the memory for fwft_hart_state is allocated by?
> > sbi_zalloc, which ensures that flags is 0. So no additional code
> > is needed to clear the SBI_FWFT_SET_FLAG_LOCK bit.
>
> That allocation only occurs the first time a hart is started. After a
> sbi_hsm_hart_stop() and sbi_hsm_hart_start(), the FWFT features will be reset to
> their default values per the SBI spec, and the flags need to be reset as well.
>
Yes, you are right, I ignored the situation you mentioned.
Regards,
Xiang W
> Regards,
> Samuel
>
> > > ---
> > > ?lib/sbi/sbi_fwft.c | 15 +++++++++++++++
> > > ?1 file changed, 15 insertions(+)
> > >
> > > diff --git a/lib/sbi/sbi_fwft.c b/lib/sbi/sbi_fwft.c
> > > index 9cf14c16..0cb165b4 100644
> > > --- a/lib/sbi/sbi_fwft.c
> > > +++ b/lib/sbi/sbi_fwft.c
> > > @@ -311,6 +311,18 @@ static int fwft_get_feature(enum sbi_fwft_feature_t feature,
> > > ? return SBI_SUCCESS;
> > > ?}
> > > ?
> > > +static void fwft_clear_config_lock(enum sbi_fwft_feature_t feature)
> > > +{
> > > + int ret;
> > > + struct fwft_config *conf;
> > > +
> > > + ret = fwft_get_feature(feature, &conf);
> > > + if (ret)
> > > + return;
> > > +
> > > + conf->flags &= ~SBI_FWFT_SET_FLAG_LOCK;
> > > +}
> > > +
> > > ?int sbi_fwft_set(enum sbi_fwft_feature_t feature, unsigned long value,
> > > ? unsigned long flags)
> > > ?{
> > > @@ -414,5 +426,8 @@ int sbi_fwft_init(struct sbi_scratch *scratch, bool cold_boot)
> > > ? fwft_set_hart_state_ptr(scratch, fhs);
> > > ? }
> > > ?
> > > + for (i = 0; i < array_size(features); i++)
> > > + fwft_clear_config_lock(features[i].id);
> > > +
> > > ? return 0;
> > > ?}
> > > --
> > > 2.34.1
> > >
> > >
> >
> >
>
>
next prev parent reply other threads:[~2024-11-22 4:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-15 7:33 [PATCH] sbi: fwft: clear the config lock when warm boot Nick Hu
2024-11-22 2:45 ` Xiang W
2024-11-22 3:24 ` Samuel Holland
2024-11-22 4:06 ` Xiang W [this message]
2024-11-28 6:44 ` Anup Patel
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=18291f649c4da495a0fdb0fde704c8bb536c7dad.camel@126.com \
--to=wxjstz@126.com \
--cc=opensbi@lists.infradead.org \
/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