On Wed, 21 Jan 2026 13:27:38 +0000 Jonathan Cameron via qemu development <[email protected]> wrote:
> On Wed, 21 Jan 2026 12:25:15 +0100 > Mauro Carvalho Chehab <[email protected]> wrote: > ... > > +class DecodeDMAVT(): > > + """ > > + Class to decode a DMA Virtualization Technology Error as defined at > > + UEFI 2.2 - N.2.2 Section Descriptor > As below. Feels like it should be > > N2.11.2 Intel VT for Directed I/O specific DMAr Error Section Descriptor. > Same for other places this comment exists. when reviewing the ghes.c driver, Igor requested to pick the oldest possible spec when filling comments inside GHES. In this specific case, the oldest one is UEFI 2.2: https://uefi.org/sites/default/files/resources/UEFI_Spec_2_2_D.pdf > > + """ > > + > > + # GUID for DMA VT Error > > + guid = "71761d37-32b2-45cd-a7d0-b0fedd93e8cf" ... there, at: N.2.2 Section Descriptor Table 227. Section Descriptor Section Type shows several different GUIDs, including this one, listed there as: Intel® VT for Directed I/O specific DMAr section •{0x71761D37, 0x32B2, 0x45cd, {0xA7, 0xD0, 0xB0, •0xFE 0xDD, 0x93, 0xE8, 0xCF}} That's basically why it is listed here for all the 9 GUIDs defined at UEFI 2.2. > > > +class DecodeDMAIOMMU(): > > + """ > > + Class to decode an IOMMU DMA Error as defined at > > + UEFI 2.2 - N.2.2 Section Descriptor > > Odd reference choice. > This stuff is in N2.11.3 IOMMU Specific DMAr Error Section > in 2.11. I'm too lazy to find it in the older spec. Heh, most of the time I spent writing this patch were to seek what spec version introduced each GUID ;-D > > > + """ > > + > > + # GUID for IOMMU DMA Error > > Maybe call it the IOMMU Specific DMAr Error > > > + guid = "036f84e1-7f37-428c-a79e-575fdfaa84ec" > > + > > + fields = [ > > > +class DecodeCXLCompEvent(): > > + """ > > + Class to decode a CXL Component Error as defined at > > + UEFI 2.9 - N.2.14. CXL Component Events Section > > + > > + Currently, the decoder handles only the common fields, displaying > > + the CXL Component Event Log field in bytes. > > + """ > > + > > + # GUIDs, as defined at CXL specification 3.2: 8.2.10.2.1 Event Records > > + guids = [ > > + ("General Media", > > "fbcd0a77-c260-417f-85a9-088b1621eba6"), > > + ("DRAM", > > "601dcbb3-9c06-4eab-b8af-4e9bfb5c9624"), > > + ("Memory Module", > > "fe927475-dd59-4339-a586-79bab113bc74"), > > + ("Memory Sparing", > > "e71f3a40-2d29-4092-8a39-4d1c966c7c65"), > > + ("Physical Switch", > > "77cf9271-9c02-470b-9fe4-bc7b75f2da97"), > > As per earlier patch review I'm not sure we care about this and the following. > I don't think we'll ever see them in CPER records, unless going other > something > else that encapsulates that format. I'm adding a notice before this table. > > > + ("Virtual Switch", > > "40d26425-3396-4c4d-a5da-3d472a63af25"), > > + ("MDL Port", > > "8dc44363-0c96-4710-b7bf-04bb99534c3f"), > MLD -> Multi-Logical Device > > > + ("Dynamic Capabilities", > > "ca95afa7-f183-4018-8c2f-95268e101a2a"), > > + ] > > + > > + fields = [ > > + ("Validation Bits", 8, "int"), > > + ("Device ID", 12, "int"), > > + ("Device Serial Number", 8, "int") > > + ] > > + > > + def __init__(self, cper: DecodeField): > > + self.cper = cper > > + > > + def decode(self, guid): > > + """Decode CXL Protocol Error""" > > + for name, guid_event in DecodeCXLCompEvent.guids: > > + if guid == guid_event: > > + print(f"CXL {name} Event Record") > > + break > > + > > + val = self.cper.decode("Length", 4, "int") > > + try: > > + length = int.from_bytes(val, byteorder='little') > > + except ValueError, TypeError: > > + length = 0 > > + > > + for name, size, ftype in self.fields: > > + self.cper.decode(name, size, ftype) > > + > > + length = max(0, length - self.cper.pos) > > + > > + self.cper.decode("CXL Component Event Log", length, "int", > > + show_incomplete=True) > > + > > + @staticmethod > > + def decode_list(): > > + """ > > + Returns a tuple with the GUID and class > > + """ > > + > > + guid_list = [] > > + > > + for _, guid in DecodeCXLCompEvent.guids: > > + guid_list.append((guid, DecodeCXLCompEvent)) > > + > > + return guid_list > > > ... > > > +class DecodeGhesEntry(): > > + """ > > + Class to decode a GHESv2 element, as defined at: > > + ACPI 6.1: 18.3.2.8 Generic Hardware Error Source version 2 > > + """ > > + > > + # Fields present on all CPER records > > + common_fields = [ > > + # Generic Error Status Block fields > > + ("Block Status", 4, "int", None), > > + ("Raw Data Offset", 4, "int", "raw_data_offset"), > > + ("Raw Data Length", 4, "int", "raw_data_len"), > > + ("Data Length", 4, "int", None), > > + ("Error Severity", 4, "int", None), > > + > > + # Generic Error Data Entry > > + ("Section Type", 16, "guid", "session_type"), > > Why session_type? Is idea it's the type of decode session we are > doing? Feels a bit too much like a typo from section_type. it is meant to be a dict key, but I'll just drop it, taking a different approach. > > + ("Error Severity", 4, "int", None), > > + ("Revision", 2, "int", None), > > + ("Validation Bits", 1, "int", None), > > + ("Flags", 1, "int", None), > > + ("Error Data Length", 4, "int", None), > > + ("FRU Id", 16, "guid", None), > > + ("FRU Text", 20, "str", None), > > + ("Timestamp", 8, "bcd", None), > > + ] > > + > > + def __init__(self, cper_data: bytearray): > > + """ > > + Initializes a byte array, decoding it, printing results at the > > + screen. > > + """ > > ... > > > + > > + # Handle common types > > + cper = DecodeField(cper_data) > > + > > + fields = {} > > + for name, size, ftype, var in self.common_fields: > > + val = cper.decode(name, size, ftype) > > + > > + if ftype == "int": > > + try: > > + val = int.from_bytes(val, byteorder='little') > > + except ValueError, TypeError: > > + val = 0 > > + > > + if var is not None: > > + fields[var] = val > > + > > + if fields["raw_data_len"]: > > + cper.decode("Raw Data", fields["raw_data_len"], > > + "int", pos=fields["raw_data_offset"]) > > + > > + if not fields["session_type"]: > > + return > >
