From nobody Thu Dec 18 15:41:23 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 81CA6204582 for ; Fri, 6 Dec 2024 17:21:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1733505688; cv=none; b=mkuu4YYZnVi1m8yImB/UvuU88Pkg9O/uO/0fS9ijasij3k+XN/Ia55lryJJMvSyFu08+V9HFQDdgHfVYMPUgkJGeTlORSmXjppOrmO1X9xFV4sqkOvUaccmeugKWgej2H7AydfyloyeNu7HtzCHRNOngT7ne5ve9BXZqHqr4LTc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1733505688; c=relaxed/simple; bh=I+JEPNOmxK5peel4DRzhTq9WP6nim8bwrqmeY99lxXI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GwTwvcgxSER9YklOI9UsmwLGeILatQDb0i367qJaz3yQ2I4nQp7u1J3VbJ3GhrQOVN/uKHUwMT8CJmnCUSyDyL89/Ml9hJvkgnyHtpYlyVv7vFqFsKFgEoNT0+3zZgwnYd4/SvjyG/ZQsmxPeex8C3TcdigEV/7OuB/p/hxCFfA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Uq7lj3JA; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Uq7lj3JA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0744CC4CEE5; Fri, 6 Dec 2024 17:21:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733505688; bh=I+JEPNOmxK5peel4DRzhTq9WP6nim8bwrqmeY99lxXI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Uq7lj3JAj5a611SqfCuBJsj4jQ4RaLdq84TdqvwEJSJik4qG7Zbh5oDyXGoJGm6nQ 15z4jmbcfd07QEnlFXXvPyv0nKsZ8oGSWUJxFmgfm/3/pLGUw9h6Ss6kpiwbnjoo5C nzQMM145WD4iDHai+H6T/ZfHSDdvquz5+xtlixx/OoHA6/HJHJ5s13FNhSJTB0DnOZ nQvVnyvxfEtiitkzAp4Qfjia2ibc3e2ezL19yTDswyv3FeipG/nd313c4T6XxtjMdk HsnrB72KgW6jndHP8PiNB1vQWnUZvXySPg4CaWtIgDIz5MSKAMdAAMhaS0ZtCBwbT2 lva7g1eW9Y7Bw== Received: from mchehab by mail.kernel.org with local (Exim 4.98) (envelope-from ) id 1tJc18-00000005RLC-0nJ9; Fri, 06 Dec 2024 18:21:26 +0100 From: Mauro Carvalho Chehab To: "Michael S . Tsirkin" Cc: Jonathan Cameron , Shiju Jose , Mauro Carvalho Chehab , Ani Sinha , Dongjiu Geng , Igor Mammedov , linux-kernel@vger.kernel.org, qemu-arm@nongnu.org, qemu-devel@nongnu.org Subject: [PATCH 26/31] acpi/ghes: move offset calculus to a separate function Date: Fri, 6 Dec 2024 18:12:48 +0100 Message-ID: <0a73530b8d48f3bd0534b1e371195405434542b4.1733504943.git.mchehab+huawei@kernel.org> X-Mailer: git-send-email 2.47.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sender: Mauro Carvalho Chehab Content-Type: text/plain; charset="utf-8" Currently, CPER address location is calculated as an offset of the hardware_errors table. It is also badly named, as the offset actually used is the address where the CPER data starts, and not the beginning of the error source. Move the logic which calculates such offset to a separate function, in preparation for a patch that will be changing the logic to calculate it from the HEST table. While here, properly name the variable which stores the cper address. Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Jonathan Cameron Reviewed-by: Igor Mammedov --- hw/acpi/ghes.c | 40 +++++++++++++++++++++++++++++++--------- 1 file changed, 31 insertions(+), 9 deletions(-) diff --git a/hw/acpi/ghes.c b/hw/acpi/ghes.c index 90d76b9c2d8c..a4453ee357bc 100644 --- a/hw/acpi/ghes.c +++ b/hw/acpi/ghes.c @@ -364,10 +364,37 @@ void acpi_ghes_add_fw_cfg(AcpiGhesState *ags, FWCfgSt= ate *s, ags->present =3D true; } =20 +static void get_hw_error_offsets(uint64_t ghes_addr, + uint64_t *cper_addr, + uint64_t *read_ack_register_addr) +{ + if (!ghes_addr) { + return; + } + + /* + * non-HEST version supports only one source, so no need to change + * the start offset based on the source ID. Also, we can't validate + * the source ID, as it is stored inside the HEST table. + */ + + cpu_physical_memory_read(ghes_addr, cper_addr, + sizeof(*cper_addr)); + + *cper_addr =3D le64_to_cpu(*cper_addr); + + /* + * As the current version supports only one source, the ack offset is + * just sizeof(uint64_t). + */ + *read_ack_register_addr =3D ghes_addr + + ACPI_GHES_ERROR_SOURCE_COUNT * sizeof(uint64_t); +} + void ghes_record_cper_errors(const void *cper, size_t len, uint16_t source_id, Error **errp) { - uint64_t error_block_addr, read_ack_register_addr, read_ack_register = =3D 0; + uint64_t cper_addr =3D 0, read_ack_register_addr =3D 0, read_ack_regis= ter; uint64_t start_addr; AcpiGedState *acpi_ged_state; AcpiGhesState *ags; @@ -389,18 +416,13 @@ void ghes_record_cper_errors(const void *cper, size_t= len, =20 start_addr +=3D source_id * sizeof(uint64_t); =20 - cpu_physical_memory_read(start_addr, &error_block_addr, - sizeof(error_block_addr)); + get_hw_error_offsets(start_addr, &cper_addr, &read_ack_register_addr); =20 - error_block_addr =3D le64_to_cpu(error_block_addr); - if (!error_block_addr) { + if (!cper_addr) { error_setg(errp, "can not find Generic Error Status Block"); return; } =20 - read_ack_register_addr =3D start_addr + - ACPI_GHES_ERROR_SOURCE_COUNT * sizeof(uint64_= t); - cpu_physical_memory_read(read_ack_register_addr, &read_ack_register, sizeof(read_ack_register)= ); =20 @@ -421,7 +443,7 @@ void ghes_record_cper_errors(const void *cper, size_t l= en, &read_ack_register, sizeof(uint64_t)); =20 /* Write the generic error data entry into guest memory */ - cpu_physical_memory_write(error_block_addr, cper, len); + cpu_physical_memory_write(cper_addr, cper, len); =20 return; } --=20 2.47.1