[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240103175047.00001a55@Huawei.com>
Date: Wed, 3 Jan 2024 17:50:47 +0000
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: Ira Weiny <ira.weiny@...el.com>
CC: Smita Koralahalli <Smita.KoralahalliChannabasappa@....com>, Dan Williams
<dan.j.williams@...el.com>, Shiju Jose <shiju.jose@...wei.com>, "Yazen
Ghannam" <yazen.ghannam@....com>, Davidlohr Bueso <dave@...olabs.net>, Dave
Jiang <dave.jiang@...el.com>, Alison Schofield <alison.schofield@...el.com>,
Vishal Verma <vishal.l.verma@...el.com>, "Ard Biesheuvel" <ardb@...nel.org>,
<linux-efi@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linux-cxl@...r.kernel.org>
Subject: Re: [PATCH RFC v4 5/6] firmware/efi: Process CXL Component Events
On Tue, 19 Dec 2023 17:12:10 +0000
Jonathan Cameron <Jonathan.Cameron@...wei.com> wrote:
> On Wed, 13 Dec 2023 14:28:03 -0800
> Ira Weiny <ira.weiny@...el.com> wrote:
>
> > Jonathan Cameron wrote:
> > > On Wed, 29 Nov 2023 06:28:01 -0800
> > > Ira Weiny <ira.weiny@...el.com> wrote:
> > >
> >
> > [snip]
> >
> > > > > __packed attribute just for cper_cxl_event_rec still fails to properly
> > > > > align structure elements. Looks like, __packed attribute is needed for
> > > > > all structs (cper_cxl_event_devid and cper_cxl_event_sn) inside
> > > > > cper_cxl_event_rec.
> > > > >
> > > > > Seems easier to use global pragma instead.. I could test and obtain the
> > > > > output as expected using pragma..
> > > >
> > > > I did not know that was acceptable in the kernel but I see you used it in
> > > > cper_cxl.h before...
> > > >
> > > > Ok I'll do that and spin again.
> > > >
> > > > Thanks so much for testing this! I was out last week and still don't have
> > > > a test environment.
> > >
> > > Easy to hack into QEMU :) Hmm. I have a CCIX patch set from years ago
> > > somewhere that does similar. Would be easy to repurposed. Looks like
> > > I never published them (just told people to ask if they wanted them :( ).
> > >
> > > Anyhow, if useful I can dig them out.
> >
> > If you have a branch with them with a somewhat latest qemu that could work
> > too.
> They are ancient and based on GHES emulation that got reworked before being
> merged. I had a quick go at a forwards port but this is a bigger job than
> I expected. May be a little while :(
Working again (embarrassingly I had the error source numbers reversed due
to a merge resolution that went wrong which took me a day to find). I'll flesh
out the injection but it will basically look like normal error injection
via qmp (json records) with a bonus parameter to stick them out as via
GHESv2 / CPER rather than AER internal error. I've not figured out how
to wire HEST up for x86 emulation yet though so it's ARM virt only for now.
(HEST isn't created for x86 qemu machines whereas it is for arm virt with ras=on)
Obviously that emulation is wrong in all sorts of ways as I should be dealing
with firmware/OSPM negotiation and setting the messaging up etc but meh
- it works for exercising the code :)
On the plus side I get nice trace points using your series and Smita's one.
Quite a bit of data is 0s at the moment as I'm lazy and it's the end of the day
here - I'll fix that up later this week as I can see 'everything' in QEMU
and the register values etc are already handled via the native injection paths.
Jonathan
>
> Jonathan
>
> >
> > Ira
>
>
Powered by blists - more mailing lists