Yazen Ghannam writes:
> On Fri, Sep 25, 2020 at 09:54:06AM +0900, Punit Agrawal wrote:
>> Borislav Petkov writes:
>>
>> > 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
>> >> > struc
On Fri, Sep 25, 2020 at 11:19:40AM -0500, Yazen Ghannam wrote:
> This patch is checking if an MSR context info structure lines up with
> the MCAX register space used on Scalable MCA systems. This register
> space is defined in the AMD Processor Programming Reference for various
> products. This is
On Fri, Sep 25, 2020 at 09:54:06AM +0900, Punit Agrawal wrote:
> Borislav Petkov writes:
>
> > 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 create
On Fri, Sep 25, 2020 at 09:54:06AM +0900, Punit Agrawal wrote:
> Maybe I could've used a better choice of words - I meant to define a
> structure with meaningful member names to replace the *(ptr + i)
> accesses in the patch.
I know exactly what you mean - I had the same question during last
revie
Borislav Petkov writes:
> 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
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 lay
On 9/23/20 7:02 PM, Punit Agrawal wrote:
Borislav Petkov writes:
Smita,
pls sync the time of the box where you create the patch:
Date: Fri, 4 Sep 2020 09:04:44 -0500
but your mail headers have:
Received: from ... with mapi id 15.20.3370.019; Fri, 18 Sep 2020 14:49:12
+
Borislav Petkov writes:
> Smita,
>
> pls sync the time of the box where you create the patch:
>
> Date: Fri, 4 Sep 2020 09:04:44 -0500
>
> but your mail headers have:
>
> Received: from ... with mapi id 15.20.3370.019; Fri, 18 Sep 2020 14:49:12
> +
>
On Wed, 23 Sep 2020 at 17:39, Borislav Petkov wrote:
>
> On Wed, Sep 23, 2020 at 04:52:18PM +0200, Ard Biesheuvel wrote:
> > I think the question is why we are retaining this Reported-by header
> > to begin with. Even though the early feedback is appreciated,
> > crediting the bot for eternity for
On Wed, Sep 23, 2020 at 04:52:18PM +0200, Ard Biesheuvel wrote:
> I think the question is why we are retaining this Reported-by header
> to begin with. Even though the early feedback is appreciated,
> crediting the bot for eternity for a version of the patch that never
> got merged seems a bit exce
On Wed, 23 Sep 2020 at 16:05, Borislav Petkov wrote:
>
> Smita,
>
> pls sync the time of the box where you create the patch:
>
> Date: Fri, 4 Sep 2020 09:04:44 -0500
>
> but your mail headers have:
>
> Received: from ... with mapi id 15.20.3370.019; Fri, 18 Sep 2020 14:49:12
> +
>
Smita,
pls sync the time of the box where you create the patch:
Date: Fri, 4 Sep 2020 09:04:44 -0500
but your mail headers have:
Received: from ... with mapi id 15.20.3370.019; Fri, 18 Sep 2020 14:49:12 +
^^
On Wed, Sep 23,
Hi Smita,
A few comments below.
Smita Koralahalli writes:
> Linux Kernel uses ACPI Boot Error Record Table (BERT) to report fatal
> errors that occurred in a previous boot. The MCA errors in the BERT are
> reported using the x86 Processor Error Common Platform Error Record (CPER)
> format. Curr
Linux Kernel uses ACPI Boot Error Record Table (BERT) to report fatal
errors that occurred in a previous boot. The MCA errors in the BERT are
reported using the x86 Processor Error Common Platform Error Record (CPER)
format. Currently, the record prints out the raw MSR values and AMD relies
on the
14 matches
Mail list logo
