Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 24 Sep 2020 19:50:23 +0200
From:   Borislav Petkov <bp@alien8.de>
To:     Smita Koralahalli Channabasappa <skoralah@amd.com>,
        Punit Agrawal <punit1.agrawal@toshiba.co.jp>
Cc:     Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>,
        x86@kernel.org, linux-kernel@vger.kernel.org,
        linux-pm@vger.kernel.org, linux-edac@vger.kernel.org,
        linux-efi@vger.kernel.org, linux-acpi@vger.kernel.org,
        devel@acpica.org, Tony Luck <tony.luck@intel.com>,
        "Rafael J . Wysocki" <rjw@rjwysocki.net>,
        Len Brown <len.brown@intel.com>,
        Ard Biesheuvel <ardb@kernel.org>,
        Yazen Ghannam <yazen.ghannam@amd.com>
Subject: Re: [PATCH v4] cper, apei, mce: Pass x86 CPER through the MCA
 handling chain
Message-ID: <20200924175023.GN5030@zn.tnic>
References: <20200904140444.161291-1-Smita.KoralahalliChannabasappa@amd.com>
 <87wo0kiz6y.fsf@kokedama.swc.toshiba.co.jp>
 <20200923140512.GJ28545@zn.tnic>
 <87pn6chwil.fsf@kokedama.swc.toshiba.co.jp>
 <52c50f37-a86c-57ad-30e0-dac0857e4ef7@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <52c50f37-a86c-57ad-30e0-dac0857e4ef7@amd.com>
Precedence: bulk

On Thu, Sep 24, 2020 at 12:23:27PM -0500, Smita Koralahalli Channabasappa wrote:
> > Even though it's not defined in the UEFI spec, it doesn't mean a
> > structure definition cannot be created.

Created for what? That structure better have a big fat comment above it, what
firmware generates its layout.

> > After all, the patch is relying on some guarantee of the meaning of
> > the values and their ordering.

AFAICT, this looks like an ad-hoc definition and the moment they change
it in some future revision, that struct of yours becomes invalid so we'd
need to add another one.

> > If the patch is relying on the definitions in the SMCA spec it is a good

Yes, what SMCA spec is that?

> > idea to reference it here - both for review and providing relevant
> > context for future developers.
> 
> Okay, I agree the structure definition will make the code less arbitrary
> and provides relevant context compared to pointer arithmetic. I did not
> think this way. I can try this out if no objections.

Again, this struct better have "versioning" info because the moment your
fw people change it in some future platform, this code needs touching
again.

It probably would need touching even with the offsets if those offsets
change but at least not having it adhere to some slow-moving spec is
probably easier in case they wanna add/change fields.

So Smita, you probably should talk to fw people about how stable that
layout at ctx_info + 1 is going to be wrt future platforms so that
we make sure we only access the correct offsets, now and on future
platforms.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette