Linux CXL
 help / color / mirror / Atom feed
From: "Zhijian Li (Fujitsu)" <lizhijian@fujitsu.com>
To: Gregory Price <gourry@gourry.net>
Cc: "linux-cxl@vger.kernel.org" <linux-cxl@vger.kernel.org>,
	Jonathan Cameron <jonathan.cameron@huawei.com>,
	Dave Jiang <dave.jiang@intel.com>,
	Alison Schofield <alison.schofield@intel.com>,
	Vishal Verma <vishal.l.verma@intel.com>,
	Ira Weiny <ira.weiny@intel.com>,
	Dan Williams <dan.j.williams@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] cxl: Allow reprogramming misconfigured hdm decoders
Date: Wed, 30 Apr 2025 03:24:42 +0000	[thread overview]
Message-ID: <082de146-d5ed-4b49-ba0f-d6f018436e5b@fujitsu.com> (raw)
In-Reply-To: <aBGIMglj8r5MNAmN@gourry-fedora-PF4VCD3F>



On 30/04/2025 10:17, Gregory Price wrote:
> On Wed, Apr 30, 2025 at 09:29:15AM +0800, Li Zhijian wrote:
>> During kernel booting, CXL drivers will attempt to construct the CXL region
>> according to the pre-programed(firmware provisioning) HDM decoders.
>>
>> This construction process will fail for some reasons, in this case, the
>> userspace cli like ndctl/cxl cannot destroy nor create regions upon the
>> existing decoders.
>>
>> Introuce a new flag CXL_DECODER_F_NEED_RESET tell the driver to reset
>> the decoder during `cxl destroy-region regionN`, so that region can be
>> create again after that.
>>
> 
> My best understanding of why this is disallowed is that firmware/bios
> programmed decoders need to be locked because there is an assumption
> that the platform programmed it that way *for a reason* - and that
> changing the programming would break it (cause MCEs for other reasons,
> etc).


Hi Gregory,

Thank you for the feedback. Based on current CXL driver behavior, user-space tools
can indeed reprogram firmware-provisioned HDM decoders in practice.

For example, after a successful boot, one may destroy the auto-constructed region
via cxl destroy-region and create a new different region.
This indicates that the kernel does not inherently lock down these decoders.

As for the locking rationale you mentioned, platform vendors might enforce their policies
through mechanisms like the *Lock-On-Commit* in CXL HDM Decoder n Control Register

While platform vendors may have valid considerations (as you noted), from a driver and
end-user perspective, depending solely on firmware updates to fix transient failures
is not smooth sometimes :).


> 
> So the appropriate solution here is for the platform vendor to fix their
> firmware.
> 
> But I am not a platform people - so I will defer to them on whether my
> understanding is correct.

Yeah, it's still in the RFC stage, let's hear more voices.

Thanks
Zhijian

> 
> ~Gregory
> 
> 

  reply	other threads:[~2025-04-30  3:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-30  1:29 [RFC PATCH] cxl: Allow reprogramming misconfigured hdm decoders Li Zhijian
2025-04-30  2:17 ` Gregory Price
2025-04-30  3:24   ` Zhijian Li (Fujitsu) [this message]
2025-04-30  8:42     ` Alejandro Lucero Palau
2025-05-07  6:42       ` Zhijian Li (Fujitsu)
2025-05-07 11:10         ` Alejandro Lucero Palau

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=082de146-d5ed-4b49-ba0f-d6f018436e5b@fujitsu.com \
    --to=lizhijian@fujitsu.com \
    --cc=alison.schofield@intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=gourry@gourry.net \
    --cc=ira.weiny@intel.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vishal.l.verma@intel.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