qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gavin Shan <gshan@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: qemu-arm@nongnu.org, qemu-devel@nongnu.org,
	jonathan.cameron@huawei.com, mchehab+huawei@kernel.org,
	gengdongjiu1@gmail.com, mst@redhat.com, anisinha@redhat.com,
	peter.maydell@linaro.org, pbonzini@redhat.com,
	shan.gavin@gmail.com
Subject: Re: [PATCH v3 2/8] acpi/ghes: Increase GHES raw data maximal length to 4KiB
Date: Thu, 13 Nov 2025 03:41:06 +1000	[thread overview]
Message-ID: <54de65b4-6ba3-474a-b9b2-e128cfc9f2ef@redhat.com> (raw)
In-Reply-To: <20251112133217.41cc6df8@fedora>

Hi Igor,

On 11/12/25 10:32 PM, Igor Mammedov wrote:
> On Tue, 11 Nov 2025 14:05:23 +1000
> Gavin Shan <gshan@redhat.com> wrote:
>> On 11/11/25 12:11 AM, Igor Mammedov wrote:
>>> On Wed,  5 Nov 2025 21:44:47 +1000
>>> Gavin Shan <gshan@redhat.com> wrote:
>>>    
>>>> The current GHES raw data maximal length isn't enough for 16 consecutive
>>>> CPER errors, which will be sent to a guest with 4KiB page size on a
>>>> erroneous 64KiB host page. Note those 16 CPER errors will be contained
>>>> in one single error block, meaning all CPER errors should be identical
>>>> in terms of type and severity and all of them should be delivered in
>>>> one shot.
>>>>
>>>> Increase GHES raw data maximal length from 1KiB to 4KiB so that the
>>>> error block has enough storage space for 16 consecutive CPER errors.
>>>>
>>>> Signed-off-by: Gavin Shan <gshan@redhat.com>
>>>> ---
>>>>    docs/specs/acpi_hest_ghes.rst | 2 +-
>>>>    hw/acpi/ghes.c                | 2 +-
>>>>    2 files changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/docs/specs/acpi_hest_ghes.rst b/docs/specs/acpi_hest_ghes.rst
>>>> index aaf7b1ad11..acf31d6eeb 100644
>>>> --- a/docs/specs/acpi_hest_ghes.rst
>>>> +++ b/docs/specs/acpi_hest_ghes.rst
>>>> @@ -68,7 +68,7 @@ Design Details
>>>>        and N Read Ack Register entries. The size for each entry is 8-byte.
>>>>        The Error Status Data Block table contains N Error Status Data Block
>>>>        entries. The size for each entry is defined at the source code as
>>>> -    ACPI_GHES_MAX_RAW_DATA_LENGTH (currently 1024 bytes). The total size
>>>> +    ACPI_GHES_MAX_RAW_DATA_LENGTH (currently 4096 bytes). The total size
>>>
>>> is it safe to bump without compat glue?
>>>
>>> consider VM migrated from old QEMU to new one,
>>> it will have  etc/hardware_errors allocated with 1K GESB,
>>> and more importantly error_block_addressN will have 1K offsets as well
>>>
>>> however with ACPI_GHES_MAX_RAW_DATA_LENGTH all length checks will
>>> let >1K blocks to be written into into 1K 'formated' etc/hardware_errors.
>>>
>>> Thanks to previous refactoring we get all addresses right (1K version),
>>> but if you write large GESB there it will either overlap with the next GESB
>>> or a smaller GESB might overwrite tail of preceding large one.
>>> And in works case it's OOB when writing large GESB in the last block.
>>>
>>> Given we have to write GESB successfully or abort, there is no point
>>> in adding compat knobs. But we still need to check if GEBS will fit into
>>> whatever block size etc/hardware_errors inside guest RAM is laid out originally.
>>>    
>>
>> Good point. You're right that we're not safe for migration from old QEMU to
>> and new QEMU. So I think I need to bump vmstate_hest_state::minimum_version_id
>> in generic_event_device.c ?
> 
> that won't help,
> what would help is creating compat property (in the owner of GHES MMIO registers),
> and lower limits (to former value) for older machine types.
> That way sizes would match even if you do ping pong migration
> between old qemu and new one, since one would still be using old machine type
> for that.
> 

In v4, a compat property 'x-error-block-size' has been added, as the fence
between QEMU 10.1 and 10.2 (1KiB vs 4KiB GHES error block size).

https://lists.nongnu.org/archive/html/qemu-arm/2025-11/msg00534.html

>>
>>
>>>>        for the "etc/hardware_errors" fw_cfg blob is
>>>>        (N * 8 * 2 + N * ACPI_GHES_MAX_RAW_DATA_LENGTH) bytes.
>>>>        N is the number of the kinds of hardware error sources.
>>>> diff --git a/hw/acpi/ghes.c b/hw/acpi/ghes.c
>>>> index 06555905ce..a9c08e73c0 100644
>>>> --- a/hw/acpi/ghes.c
>>>> +++ b/hw/acpi/ghes.c
>>>> @@ -33,7 +33,7 @@
>>>>    #define ACPI_HEST_ADDR_FW_CFG_FILE          "etc/acpi_table_hest_addr"
>>>>    
>>>>    /* The max size in bytes for one error block */
>>>> -#define ACPI_GHES_MAX_RAW_DATA_LENGTH   (1 * KiB)
>>>> +#define ACPI_GHES_MAX_RAW_DATA_LENGTH   (4 * KiB)
>>>>    
>>>>    /* Generic Hardware Error Source version 2 */
>>>>    #define ACPI_GHES_SOURCE_GENERIC_ERROR_V2   10
>>

Thanks,
Gavin



  reply	other threads:[~2025-11-12 17:44 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-05 11:44 [PATCH v3 0/8] target/arm/kvm: Improve memory error handling Gavin Shan
2025-11-05 11:44 ` [PATCH v3 1/8] tests/qtest/bios-tables-test: Prepare for changes in the HEST table Gavin Shan
2025-11-05 14:16   ` Jonathan Cameron via
2025-11-05 11:44 ` [PATCH v3 2/8] acpi/ghes: Increase GHES raw data maximal length to 4KiB Gavin Shan
2025-11-05 14:16   ` Jonathan Cameron via
2025-11-10 14:11   ` Igor Mammedov
2025-11-11  4:05     ` Gavin Shan
2025-11-12 12:32       ` Igor Mammedov
2025-11-12 17:41         ` Gavin Shan [this message]
2025-11-05 11:44 ` [PATCH v3 3/8] tests/qtest/bios-tables-test: Update HEST table Gavin Shan
2025-11-05 14:17   ` Jonathan Cameron via
2025-11-05 11:44 ` [PATCH v3 4/8] acpi/ghes: Extend acpi_ghes_memory_errors() to support multiple CPERs Gavin Shan
2025-11-05 14:14   ` Jonathan Cameron via
2025-11-06  3:15     ` Gavin Shan
2025-11-10 14:49       ` Igor Mammedov
2025-11-11  4:08         ` Gavin Shan
2025-11-11 10:07           ` Jonathan Cameron via
2025-11-11 10:55             ` Gavin Shan
2025-11-11 11:55               ` Jonathan Cameron via
2025-11-11 12:19                 ` Gavin Shan
2025-11-11 13:12                   ` Jonathan Cameron via
2025-11-10 14:38   ` Igor Mammedov
2025-11-11  4:40     ` Gavin Shan
2025-11-12 13:12       ` Igor Mammedov
2025-11-12 17:36         ` Gavin Shan
2025-11-10 14:43   ` Philippe Mathieu-Daudé
2025-11-10 23:38     ` Gavin Shan
2025-11-11  3:40       ` Gavin Shan
2025-11-10 14:48   ` Philippe Mathieu-Daudé
2025-11-11  3:44     ` Gavin Shan
2025-11-05 11:44 ` [PATCH v3 5/8] acpi/ghes: Bail early on error from get_ghes_source_offsets() Gavin Shan
2025-11-05 14:17   ` Jonathan Cameron via
2025-11-10 14:50   ` Philippe Mathieu-Daudé
2025-11-11  3:48     ` Gavin Shan
2025-11-10 14:51   ` Igor Mammedov
2025-11-05 11:44 ` [PATCH v3 6/8] acpi/ghes: Use error_abort in acpi_ghes_memory_errors() Gavin Shan
2025-11-05 14:18   ` Jonathan Cameron via
2025-11-10 14:53   ` Igor Mammedov
2025-11-10 14:54   ` Philippe Mathieu-Daudé
2025-11-11  3:58     ` Gavin Shan
2025-11-12 12:49       ` Igor Mammedov
2025-11-12 17:38         ` Gavin Shan
2025-11-11  5:08     ` Markus Armbruster
2025-11-11  5:25   ` Markus Armbruster
2025-11-11  6:02     ` Gavin Shan
2025-11-11  7:31       ` Markus Armbruster
2025-11-05 11:44 ` [PATCH v3 7/8] kvm/arm/kvm: Introduce helper push_ghes_memory_errors() Gavin Shan
2025-11-05 14:19   ` Jonathan Cameron via
2025-11-10 14:56   ` Igor Mammedov
2025-11-11  4:09     ` Gavin Shan
2025-11-05 11:44 ` [PATCH v3 8/8] target/arm/kvm: Support multiple memory CPERs injection Gavin Shan
2025-11-05 14:37   ` Jonathan Cameron via
2025-11-06  3:26     ` Gavin Shan
2025-11-11 10:12       ` Jonathan Cameron via

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=54de65b4-6ba3-474a-b9b2-e128cfc9f2ef@redhat.com \
    --to=gshan@redhat.com \
    --cc=anisinha@redhat.com \
    --cc=gengdongjiu1@gmail.com \
    --cc=imammedo@redhat.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=mchehab+huawei@kernel.org \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=shan.gavin@gmail.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).