qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Igor Mammedov <imammedo@redhat.com>
Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	Shiju Jose <shiju.jose@huawei.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Ani Sinha <anisinha@redhat.com>,
	Dongjiu Geng <gengdongjiu1@gmail.com>,
	linux-kernel@vger.kernel.org, qemu-arm@nongnu.org,
	qemu-devel@nongnu.org
Subject: Re: [PATCH v8 13/13] acpi/ghes: check if the BIOS pointers for HEST are correct
Date: Sat, 24 Aug 2024 02:15:10 +0200	[thread overview]
Message-ID: <20240824021510.71451b57@sal.lan> (raw)
In-Reply-To: <20240819160733.464ccebf@imammedo.users.ipa.redhat.com>

Em Mon, 19 Aug 2024 16:07:33 +0200
Igor Mammedov <imammedo@redhat.com> escreveu:

> > +    err_source_struct = le64_to_cpu(ags->hest_addr_le) +
> > +                        source * HEST_GHES_V2_TABLE_SIZE;  
> 
> there is no guaranties that HEST table will contain only GHESv2 sources,
> and once such is added this place becomes broken.
> 
> we need to iterate over HEST taking that into account
> and find only ghesv2 structure with source id of interest.
> 
> This function (and acpi_ghes_record_errors() as well) taking source_id
> as input should be able to lookup pointers from HEST in guest RAM,
> very crude idea could look something like this:
> 
> typedef struct hest_source_type2len{
>    uint16_t type
>    int len
> } hest_structure_type2len
> 
> hest_structure_type2len supported_hest_sources[] = {
>     /* Table 18-344 Generic Hardware Error Source version 2 (GHESv2) Structure */
>     {.type = 10, .len = 92},
> }

Sounds interesting, but IMO it should be done only when other types besides
ghes would be added, as:

1. Right now, the file is acpi/ghes.c. Adding non-type 10 HEST structures
   there would be a little weird. It should likely be renamed to acpi/hest.c
   when such time comes.

2. ACPI 6.5 has made clear that the above will only work up to type 11,
   as, from type 12 and above, the length will be added to the error
   struct, according with:

   https://uefi.org/specs/ACPI/6.5/18_Platform_Error_Interfaces.html#error-source-structure-header-type-12-onward

3. some types have variable size. Starting from the beginning, type 0, as
   defined at:
   https://uefi.org/specs/ACPI/6.5/18_Platform_Error_Interfaces.html#hardware-errors-and-error-sources

   has:

   size = 40 + 24 * Number of Hardware banks

   So, a simple table like the above with fixed sizes won't work.

   The code would need instead a switch if types are <= 11.

   Adding proper support for all already defined 12 types sounds lots of 
   work, as the code would need to calculate the size depending on the
   size, and we don't really initialize the HEST table with other types
   but GHES.

Ok, we could still do something like this pseudo-code to get the
error source offset:

	#define ACPI_HEST_TYPE_GHESV2	11

	err_struct_offset = 0;
	for (i = 0; i < source_id_count; i++) {
		/* NOTE: Other types may have different sizes */
		assert(ghes[i].type == ACPI_HEST_TYPE_GHESV2);
		if (ghes[i].source_id == source_id)
			break;
		err_struct_offset += HEST_GHES_V2_TABLE_SIZE;
	}
	assert (i < source_id_count);

---

That's said, maybe this will just add unwanted complexity, as QEMU
is already setting those offsets via bios_linker_loader_add_pointer().

So, an alternative for that is to merge the code on patch 13 with the one
on patch 5, dropping the math calcus there and relying that QEMU will
always handle properly bios links.

See, the logic which constructs GHESv2 source IDs do this to create
the links between HEST ACPI table and etc/hardware_errors:

with:

Per-source ID logic at build_ghes_v2():

    address_offset = table_data->len;
    /* Error Status Address */
    build_append_gas(table_data, AML_AS_SYSTEM_MEMORY, 0x40, 0,
                     4 /* QWord access */, 0);
    bios_linker_loader_add_pointer(linker, ACPI_BUILD_TABLE_FILE,
                                   address_offset + GAS_ADDR_OFFSET,
                                   sizeof(uint64_t),
                                   ACPI_HW_ERROR_FW_CFG_FILE,
                                   source_id * sizeof(uint64_t));
...
    /*
     * Read Ack Register
     * ACPI 6.1: 18.3.2.8 Generic Hardware Error Source
     * version 2 (GHESv2 - Type 10)
     */
    address_offset = table_data->len;
    build_append_gas(table_data, AML_AS_SYSTEM_MEMORY, 0x40, 0,
                     4 /* QWord access */, 0);
    bios_linker_loader_add_pointer(linker, ACPI_BUILD_TABLE_FILE,
                                   address_offset + GAS_ADDR_OFFSET,
                                   sizeof(uint64_t),
                                   ACPI_HW_ERROR_FW_CFG_FILE,
                                   (ACPI_HEST_SRC_ID_COUNT + source_id) *
                                   sizeof(uint64_t));

HEST table creation logic inside build_ghes_error_table():

    for (i = 0; i < ACPI_HEST_SRC_ID_COUNT; i++) {
        /*
         * Tell firmware to patch error_block_address entries to point to
         * corresponding "Generic Error Status Block"
         */
        bios_linker_loader_add_pointer(linker,
            ACPI_HW_ERROR_FW_CFG_FILE, sizeof(uint64_t) * i,
            sizeof(uint64_t), ACPI_HW_ERROR_FW_CFG_FILE,
            error_status_block_offset + i * ACPI_GHES_MAX_RAW_DATA_LENGTH);
    }

Using those, the location of the CPER and ack addresses is easy and won't
require any math:

	/* GHESv2 CPER offset */
	cpu_physical_memory_read(hest_err_block_addr, &error_block_addr,
                                 sizeof(error_block_addr));
	cpu_physical_memory_read(error_block_addr, &cper_addr,
                                 sizeof(error_block_addr));

	/* GHESv2 ack offset */
	cpu_physical_memory_read(hest_read_ack_start_addr, &read_ack_start_addr,
			         sizeof(read_ack_start_addr));


Regards,
Mauro


  reply	other threads:[~2024-08-24  0:16 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-16  7:37 [PATCH v8 00/13] Add ACPI CPER firmware first error injection on ARM emulation Mauro Carvalho Chehab
2024-08-16  7:37 ` [PATCH v8 01/13] acpi/generic_event_device: add an APEI error device Mauro Carvalho Chehab
2024-08-19 11:21   ` Igor Mammedov
2024-08-16  7:37 ` [PATCH v8 02/13] arm/virt: Wire up a GED error device for ACPI / GHES Mauro Carvalho Chehab
2024-08-16  7:37 ` [PATCH v8 03/13] acpi/ghes: Add support for GED error device Mauro Carvalho Chehab
2024-08-19 11:43   ` Igor Mammedov
2024-08-23 23:28     ` Mauro Carvalho Chehab
2024-08-16  7:37 ` [PATCH v8 04/13] qapi/acpi-hest: add an interface to do generic CPER error injection Mauro Carvalho Chehab
2024-08-19 11:54   ` Igor Mammedov
2024-08-16  7:37 ` [PATCH v8 05/13] acpi/ghes: rework the logic to handle HEST source ID Mauro Carvalho Chehab
2024-08-19 12:10   ` Igor Mammedov
2024-08-25  2:02     ` Mauro Carvalho Chehab
2024-08-16  7:37 ` [PATCH v8 06/13] acpi/ghes: add support for generic error injection via QAPI Mauro Carvalho Chehab
2024-08-19 12:51   ` Igor Mammedov
2024-08-25  3:29     ` Mauro Carvalho Chehab
2024-09-11 13:21       ` Igor Mammedov
2024-09-11 15:34         ` Jonathan Cameron via
2024-09-12 12:42           ` Igor Mammedov
2024-09-13  5:20             ` Mauro Carvalho Chehab
2024-09-13 10:13               ` Jonathan Cameron via
2024-09-13 12:28                 ` Igor Mammedov
2024-09-14  5:38                   ` Mauro Carvalho Chehab
2024-08-16  7:37 ` [PATCH v8 07/13] acpi/ghes: cleanup the memory error code logic Mauro Carvalho Chehab
2024-08-16  7:37 ` [PATCH v8 08/13] docs: acpi_hest_ghes: fix documentation for CPER size Mauro Carvalho Chehab
2024-08-16  7:37 ` [PATCH v8 09/13] scripts/ghes_inject: add a script to generate GHES error inject Mauro Carvalho Chehab
2024-08-16  7:37 ` [PATCH v8 10/13] target/arm: add an experimental mpidr arm cpu property object Mauro Carvalho Chehab
2024-08-16  7:37 ` [PATCH v8 11/13] scripts/arm_processor_error.py: retrieve mpidr if not filled Mauro Carvalho Chehab
2024-08-16  7:37 ` [PATCH v8 12/13] acpi/ghes: cleanup generic error data logic Mauro Carvalho Chehab
2024-08-19 12:57   ` Igor Mammedov
2024-08-16  7:37 ` [PATCH v8 13/13] acpi/ghes: check if the BIOS pointers for HEST are correct Mauro Carvalho Chehab
2024-08-19 14:07   ` Igor Mammedov
2024-08-24  0:15     ` Mauro Carvalho Chehab [this message]
2024-08-25  3:48       ` Mauro Carvalho Chehab
2024-08-19 14:21 ` [PATCH v8 00/13] Add ACPI CPER firmware first error injection on ARM emulation Igor Mammedov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240824021510.71451b57@sal.lan \
    --to=mchehab+huawei@kernel.org \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=anisinha@redhat.com \
    --cc=gengdongjiu1@gmail.com \
    --cc=imammedo@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=shiju.jose@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).