From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Shiyang Ruan <ruansy.fnst@fujitsu.com>,
<linux-cxl@vger.kernel.org>, <dave.jiang@intel.com>,
<vishal.l.verma@intel.com>
Subject: Re: Some thoughts and questions about CXL & MCE
Date: Mon, 8 Jan 2024 12:37:49 +0000 [thread overview]
Message-ID: <20240108123749.0000027f@Huawei.com> (raw)
In-Reply-To: <65958f44d67b7_8dc68294c7@dwillia2-xfh.jf.intel.com.notmuch>
> > And a question:
> > How to configure the CXL device to choose FW-First or OS-First singal
> > methods (methods for qemu and bare matel if possible)?
>
> Honestly I am not sure it is worthwhile to have QEMU support firmware
> first vs just have a way to trigger CPER record events. The goal of the
> CXL QEMU enabling is to test OS enabling and the virtual device does not
> actually need simulate all of the Firmware-First mechanisms, the CPER
> record result is sufficient.
Agreed - one emulation wrinkle is it needs to not do some other stuff when
simulating them. I.e. we don't want to fill up event logs etc with events
we are pretending the firmware dealt with and already cleared from logs etc.
To make it useable it has to do some magic to fill in the cper record, but
that is easy enough. Control wise, reuse the existing error injection
commands.
One other wrinkle I'm working through is the control of CPER vs normal reporting.
Current thought is we do what ACPI allows and start in firmware first, until the
_OSC call. If that requests native handling we go back to what we currently
support (native only emulation).
However, there isn't a convenient way to mess with what Linux asks for which we'd
want to make it easy to test the handling once the driver stack is up.
I'm not sure anyone would be keen on a pci_aer=no-ask,cxl-mem-error=no-ask type
kernel boot parameter to instruct the kernel to never ask for control.
I also don't much like a qemu parameter which basically says 'report aer as
broken so the OS can't grab it'. Anyhow those are details.
Ah well. Getting the _OSC handshake to save what was negotiated on qemu side was
fiddly but I got that working on Friday so I have all the pieces for protocol errors
done (ARM only for now - I need to look at notifications in ACPI on x86 + enable
HEST in general on qemu-x86). Will post an RFC for ARM shortly.
Bare metal will be burried in bios config most likely.
Jonathan
>
> > I don't fully understand the CXL spec yet (it's difficult for me), so
> > the above ideas may be immature, but I really want to figure out how we
> > can make CXL & MCE work. I'd really appreciate it if you could help me
> > on this!
> >
> > [1]
> > https://lore.kernel.org/linux-cxl/20231220-cxl-cper-v5-0-1bb8a4ca2c7a@intel.com/T/#u
>
> Following this work from Smita and Ira is the right path.
next prev parent reply other threads:[~2024-01-08 12:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-22 16:33 Some thoughts and questions about CXL & MCE Shiyang Ruan
2024-01-02 17:29 ` Jonathan Cameron
2024-01-03 16:45 ` Dan Williams
2024-01-08 12:37 ` Jonathan Cameron [this message]
2024-01-08 21:14 ` Dan Williams
2024-01-09 16:18 ` Jonathan Cameron
2024-01-09 19:59 ` Dan Williams
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=20240108123749.0000027f@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=linux-cxl@vger.kernel.org \
--cc=ruansy.fnst@fujitsu.com \
--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