All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@suse.de>
To: "Ghannam, Yazen" <Yazen.Ghannam@amd.com>
Cc: Tony Luck <tony.luck@intel.com>,
	"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"ard.biesheuvel@linaro.org" <ard.biesheuvel@linaro.org>,
	"x86@kernel.org" <x86@kernel.org>
Subject: Re: [PATCH v2 0/8] Decode IA32/X64 CPER
Date: Wed, 28 Feb 2018 17:35:39 +0100	[thread overview]
Message-ID: <20180228163539.GC2969@pd.tnic> (raw)
In-Reply-To: <DM5PR12MB1916B6CA08F0D423B3635EDDF8C70@DM5PR12MB1916.namprd12.prod.outlook.com>

On Wed, Feb 28, 2018 at 03:12:09PM +0000, Ghannam, Yazen wrote:
> CPER is the format used for BERT, etc. We'll only ever see a CPER if the
> firmware creates it. And it's up to firmware policy what is shared with
> the OS.

Yap, but we should still tie it into our infra.

> My main reason for printing all the info is that it may be too difficult or too
> late to gather that info after the fact. I think this is especially true for boot
> errors, though maybe there's another way that I don't know about
> (re-reading BERT later?).

So that BERT thing is a table, AFAIR. I don't see why it would be a
problem if we read it later, at our leisure and free the record only
when we're done.

Looking at bert.c is entered with a late_initcall() which is nicely late
and we have everything up and ready to process errors then.

> Right. I want to work on getting this more integrated with our existing
> x86 infrastructure. But I don't want to wait until we figure all that out
> before we have some sort of CPER decoding.

Just keep in mind that whenever you expose stuff and userspace starts
using it, it is much harder to change it. So let's do it right pls.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

  reply	other threads:[~2018-02-28 16:36 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-26 19:38 [PATCH v2 0/8] Decode IA32/X64 CPER Yazen Ghannam
2018-02-26 19:38 ` [PATCH v2 1/8] efi: Fix IA32/X64 Processor Error Record definition Yazen Ghannam
2018-02-27 10:47   ` Borislav Petkov
2018-02-27 15:05     ` Ghannam, Yazen
2018-02-26 19:38 ` [PATCH v2 2/8] efi: Decode IA32/X64 Processor Error Section Yazen Ghannam
2018-02-27 11:22   ` Borislav Petkov
2018-02-27 15:13     ` Ghannam, Yazen
2018-02-27 17:00       ` Borislav Petkov
2018-02-27 17:27         ` Ghannam, Yazen
2018-02-27 17:44           ` Borislav Petkov
2018-02-27 18:06             ` Ghannam, Yazen
2018-02-27 18:34               ` Borislav Petkov
2018-02-26 19:38 ` [PATCH v2 3/8] efi: Decode IA32/X64 Processor Error Info Structure Yazen Ghannam
2018-02-27 14:25   ` Borislav Petkov
2018-02-27 15:25     ` Ghannam, Yazen
2018-02-27 17:04       ` Borislav Petkov
2018-02-27 17:46         ` Ghannam, Yazen
2018-02-27 18:02           ` Borislav Petkov
2018-02-27 18:40             ` Ghannam, Yazen
2018-02-27 19:09               ` Borislav Petkov
2018-02-27 21:32                 ` Ghannam, Yazen
2018-02-27 22:10                   ` Borislav Petkov
2018-02-26 19:39 ` [PATCH v2 4/8] efi: Decode UEFI-defined IA32/X64 Error Structure GUIDs Yazen Ghannam
2018-02-27 14:30   ` Borislav Petkov
2018-02-27 15:28     ` Ghannam, Yazen
2018-02-27 15:31       ` Ard Biesheuvel
2018-02-26 19:39 ` [PATCH v2 5/8] efi: Decode IA32/X64 Cache, TLB, and Bus Check structures Yazen Ghannam
2018-02-27 15:03   ` Borislav Petkov
2018-02-27 15:33     ` Ghannam, Yazen
2018-02-27 17:06       ` Borislav Petkov
2018-02-26 19:39 ` [PATCH v2 6/8] efi: Decode additional IA32/X64 Bus Check fields Yazen Ghannam
2018-02-26 19:39 ` [PATCH v2 7/8] efi: Decode IA32/X64 MS Check structure Yazen Ghannam
2018-02-26 19:39 ` [PATCH v2 8/8] efi: Decode IA32/X64 Context Info structure Yazen Ghannam
2018-02-28  8:43 ` [PATCH v2 0/8] Decode IA32/X64 CPER Borislav Petkov
2018-02-28 15:12   ` Ghannam, Yazen
2018-02-28 16:35     ` Borislav Petkov [this message]
2018-02-28 20:58       ` Ghannam, Yazen
2018-03-01 11:59         ` Borislav Petkov
2018-03-23  0:19           ` Ghannam, Yazen
2018-03-23 15:29             ` Borislav Petkov
2018-03-01 16:38   ` Luck, Tony

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=20180228163539.GC2969@pd.tnic \
    --to=bp@suse.de \
    --cc=Yazen.Ghannam@amd.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.