From nobody Thu Nov 28 16:32:33 2024 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 E848C17BB1E for ; Fri, 22 Nov 2024 09:11:48 +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=1732266709; cv=none; b=TE91LLQakv/uJAibffm4+05tKKtr5wi5/nyy9lRnDuZDBfnW7/zMTT2JlC/uR7yltX3LbfmfeVWfq9JnRInglg520kaSo1CAhIns1qPcO6Ba4YETaVKTiLg/IMrEY1bMfBf9Ye16Mh9TVnrky+mVLxUt/q1rMDo79ORmu5Zsfyo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732266709; c=relaxed/simple; bh=hJXdm+o+Qg2Q0Ak/9rfyKRugnUJHbORHdHLMHQnys24=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rRIhMtHKCtsQIKmSNSvXn3UVAr68N+1YjEvmwlwxT5sCvLgj9nqVV+JiUnDHm8fHI3mhVHs/5VjKoPCWYcPK3J9zRCqS788NoHfj0KGTT8yV0mqWYsc/3zGqPL/vXNULNiKtl3akL7JKmrSEsUZJivFFMLjdXBKaP0eLzUxIlfw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bXchZ+Py; 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="bXchZ+Py" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 76C05C4CED1; Fri, 22 Nov 2024 09:11:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1732266708; bh=hJXdm+o+Qg2Q0Ak/9rfyKRugnUJHbORHdHLMHQnys24=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bXchZ+Pyl9gL0P0J3RAOfRkZGPQMToOi8b3/NLYLu6PDbUgyyFIyRnKOOtdj/vzmJ GLH5FEHFHYiG9p0S1NLcG85bIik3neETZ1TbG9qllnP079i0E8sJzK0oL0ADWhJRJI r3UZapF1u/5tdFcmTpYud6s9A+7uurEZh7u/Zaem9LnwHIVppFinV/NDjJxKzTL6yd /Zr3+qmSEwymL9VTS+tR4+SAkPOUGdPI2FMAOjfJVy0+hpgdGzMMvc65NxhHygebB0 hKdMlZdlAK9E40wzC1pbCVV8jV1TIBL2SJYkllY1rA65aqEJ4W7xLE9XvhJ+2FzmGy D5LOwh/BRtr7w== Received: from mchehab by mail.kernel.org with local (Exim 4.98) (envelope-from ) id 1tEPhX-00000006l4A-1CV3; Fri, 22 Nov 2024 10:11:43 +0100 From: Mauro Carvalho Chehab To: Igor Mammedov Cc: Jonathan Cameron , Shiju Jose , Mauro Carvalho Chehab , "Michael S. Tsirkin" , Ani Sinha , Dongjiu Geng , linux-kernel@vger.kernel.org, qemu-arm@nongnu.org, qemu-devel@nongnu.org Subject: [PATCH v4 13/15] acpi/ghes: move offset calculus to a separate function Date: Fri, 22 Nov 2024 10:11:30 +0100 Message-ID: X-Mailer: git-send-email 2.47.0 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 --- hw/acpi/ghes.c | 41 ++++++++++++++++++++++++++++++++--------- 1 file changed, 32 insertions(+), 9 deletions(-) diff --git a/hw/acpi/ghes.c b/hw/acpi/ghes.c index 87fd3feedd2a..d99697b20164 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,14 @@ 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) { + cper_addr =3D le64_to_cpu(cper_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 +444,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.0