> -----Original Message----- > From: Borislav Petkov [mailto:bp@xxxxxxx] > Sent: Tuesday, February 27, 2018 9:26 AM > To: Ghannam, Yazen <Yazen.Ghannam@xxxxxxx> > Cc: linux-efi@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > ard.biesheuvel@xxxxxxxxxx; x86@xxxxxxxxxx > Subject: Re: [PATCH v2 3/8] efi: Decode IA32/X64 Processor Error Info > Structure > > On Mon, Feb 26, 2018 at 01:38:59PM -0600, Yazen Ghannam wrote: > > From: Yazen Ghannam <yazen.ghannam@xxxxxxx> > > > > Print the fields in the IA32/X64 Processor Error Info Structure. > > > > Based on UEFI 2.7 Table 256. IA32/X64 Processor Error Information > > Structure. > > > > Signed-off-by: Yazen Ghannam <yazen.ghannam@xxxxxxx> > > --- > > Link: > > https://lkml.kernel.org/r/20180223200333.6410-4- > Yazen.Ghannam@xxxxxxx > > > > v1->v2: > > * Add parantheses around "bits" expression in macro. > > * Fix indentation on multi-line statements. > > > > drivers/firmware/efi/cper-x86.c | 53 > +++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 53 insertions(+) > > > > diff --git a/drivers/firmware/efi/cper-x86.c b/drivers/firmware/efi/cper- > x86.c > > index 9da0d981178f..417bd4e500a7 100644 > > --- a/drivers/firmware/efi/cper-x86.c > > +++ b/drivers/firmware/efi/cper-x86.c > > @@ -3,15 +3,28 @@ > > > > #include <linux/cper.h> > > > > +#define INDENT_SP " " > > That's just silly. > This is the same as the other CPER code. > > + > > /* > > * We don't need a "CPER_IA" prefix since these are all locally defined. > > * This will save us a lot of line space. > > */ > > #define VALID_LAPIC_ID BIT_ULL(0) > > #define VALID_CPUID_INFO BIT_ULL(1) > > +#define VALID_PROC_ERR_INFO_NUM(bits) (((bits) & GENMASK_ULL(7, > 2)) >> 2) > > + > > +#define INFO_VALID_CHECK_INFO BIT_ULL(0) > > +#define INFO_VALID_TARGET_ID BIT_ULL(1) > > +#define INFO_VALID_REQUESTOR_ID BIT_ULL(2) > > +#define INFO_VALID_RESPONDER_ID BIT_ULL(3) > > +#define INFO_VALID_IP BIT_ULL(4) > > > > void cper_print_proc_ia(const char *pfx, const struct cper_sec_proc_ia > *proc) > > { > > + int i; > > + struct cper_ia_err_info *err_info; > > + char newpfx[64]; > > + > > printk("%sValidation Bits: 0x%016llx\n", pfx, proc->validation_bits); > > > > if (proc->validation_bits & VALID_LAPIC_ID) > > @@ -22,4 +35,44 @@ void cper_print_proc_ia(const char *pfx, const struct > cper_sec_proc_ia *proc) > > print_hex_dump(pfx, "", DUMP_PREFIX_OFFSET, 16, 4, proc- > >cpuid, > > sizeof(proc->cpuid), 0); > > } > > + > > + snprintf(newpfx, sizeof(newpfx), "%s%s", pfx, INDENT_SP); > > + > > + err_info = (struct cper_ia_err_info *)(proc + 1); > > + for (i = 0; i < VALID_PROC_ERR_INFO_NUM(proc->validation_bits); > i++) { > > + printk("%sError Information Structure %d:\n", pfx, i); > > + > > + printk("%sError Structure Type: %pUl\n", newpfx, > > + &err_info->err_type); > > That dumps a GUID - how do I find out what type that GUID refers to? > A later patch prints out the spec-defined type. Also, the spec allows platform-defined GUIDs. So we should always print this even if the GUID is not defined by the spec. > > + > > + printk("%sValidation Bits: 0x%016llx\n", > > + newpfx, err_info->validation_bits); > > As before, no need for those. > > > + > > + if (err_info->validation_bits & INFO_VALID_CHECK_INFO) { > > + printk("%sCheck Information: 0x%016llx\n", newpfx, > > + err_info->check_info); > > + } > > + > > + if (err_info->validation_bits & INFO_VALID_TARGET_ID) { > > + printk("%sTarget Identifier: 0x%016llx\n", > > + newpfx, err_info->target_id); > > + } > > + > > + if (err_info->validation_bits & INFO_VALID_REQUESTOR_ID) { > > + printk("%sRequestor Identifier: 0x%016llx\n", > > + newpfx, err_info->requestor_id); > > + } > > + > > + if (err_info->validation_bits & INFO_VALID_RESPONDER_ID) { > > + printk("%sResponder Identifier: 0x%016llx\n", > > + newpfx, err_info->responder_id); > > + } > > Those look like would need an additional decoding. Can we do that here > too? > The Check Information will be decoded further in another patch. I don't think there's much else to decode for the ID fields. > > + > > + if (err_info->validation_bits & INFO_VALID_IP) { > > + printk("%sInstruction Pointer: 0x%016llx\n", > > + newpfx, err_info->ip); > > The only thing that makes sense so far. > > > + } > > + > > + err_info++; > > + } > > Also, it is worth checking how much duplication there is with > drivers/firmware/efi/cper-arm.c and unifying the common pieces into > functions in cper-common.c or so. > Other tables may have the same fields but the offsets are usually different. So it may be more trouble than it's worth trying to unify the different tables. Thanks, Yazen ��.n��������+%������w��{.n�����{����* jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
