qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gavin Shan <gshan@redhat.com>
To: qemu-arm@nongnu.org
Cc: qemu-devel@nongnu.org, jonathan.cameron@huawei.com,
	mchehab+huawei@kernel.org, gengdongjiu1@gmail.com,
	mst@redhat.com, imammedo@redhat.com, armbru@redhat.com,
	anisinha@redhat.com, eduardo@habkost.net,
	marcel.apfelbaum@gmail.com, philmd@linaro.org,
	wangyanan55@huawei.com, zhao1.liu@intel.com,
	peter.maydell@linaro.org, pbonzini@redhat.com,
	shan.gavin@gmail.com
Subject: [PATCH v4 8/8] target/arm/kvm: Support multiple memory CPERs injection
Date: Thu, 13 Nov 2025 03:25:35 +1000	[thread overview]
Message-ID: <20251112172535.403042-9-gshan@redhat.com> (raw)
In-Reply-To: <20251112172535.403042-1-gshan@redhat.com>

In the combination of 64KiB host and 4KiB guest, a problematic host
page affects 16x guest pages that can be owned by different threads.
It means 16x memory errors can be raised at once due to the parallel
accesses to those 16x guest pages on the guest. Unfortunately, QEMU
can't deliver them one by one because we just have one GHES error block,
corresponding to one read acknowledgement register. It can eventually
cause QEMU crash dump due to the contention on that register, meaning
the current memory error can't be delivered before the previous error
isn't acknowledged.

Move the logics of sending ACPI GHES memory errors and injects SEA
exception to a newly added helper push_ghes_memory_errors(). Improve
push_ghes_memory_errors() to push 16x consecutive memory errors if
needed to avoid the contention on the read acknowledgement register,
thus the exceptional termination on QEMU.

Signed-off-by: Gavin Shan <gshan@redhat.com>
---
 target/arm/kvm.c | 70 +++++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 64 insertions(+), 6 deletions(-)

diff --git a/target/arm/kvm.c b/target/arm/kvm.c
index b8c3ad2ad9..3da97664eb 100644
--- a/target/arm/kvm.c
+++ b/target/arm/kvm.c
@@ -11,6 +11,7 @@
  */
 
 #include "qemu/osdep.h"
+#include "qemu/units.h"
 #include <sys/ioctl.h>
 
 #include <linux/kvm.h>
@@ -2429,12 +2430,73 @@ int kvm_arch_get_registers(CPUState *cs, Error **errp)
     return ret;
 }
 
+static bool push_ghes_memory_errors(CPUState *c, AcpiGhesState *ags,
+                                    uint64_t paddr, Error **errp)
+{
+    uint64_t val, start, end, guest_pgsz, host_pgsz;
+    uint64_t addresses[16];
+    uint32_t num_of_addresses;
+    int err;
+    bool ret;
+
+    /*
+     * Sort out the guest page size from TCR_EL1, which can be modified
+     * by the guest from time to time. So we have to sort it out dynamically.
+     */
+    err = read_sys_reg64(c->kvm_fd, &val, ARM64_SYS_REG(3, 0, 2, 0, 2));
+    if (err) {
+        error_setg(errp, "Error %" PRId32 " to read TCR_EL1 register", err);
+        return false;
+    }
+
+    switch (extract64(val, 14, 2)) {
+    case 0:
+        guest_pgsz = 4 * KiB;
+        break;
+    case 1:
+        guest_pgsz = 64 * KiB;
+        break;
+    case 2:
+        guest_pgsz = 16 * KiB;
+        break;
+    default:
+        error_setg(errp, "Unknown page size from TCR_EL1 (0x%" PRIx64 ")", val);
+        return false;
+    }
+
+    host_pgsz = qemu_real_host_page_size();
+    start = paddr & ~(host_pgsz - 1);
+    end = start + host_pgsz;
+    num_of_addresses = 0;
+
+    while (start < end) {
+        /*
+         * The precise physical address is provided for the affected
+         * guest page that contains @paddr. Otherwise, the starting
+         * address of the guest page is provided.
+         */
+        if (paddr >= start && paddr < (start + guest_pgsz)) {
+            addresses[num_of_addresses++] = paddr;
+        } else {
+            addresses[num_of_addresses++] = start;
+        }
+
+        start += guest_pgsz;
+    }
+
+    kvm_cpu_synchronize_state(c);
+    ret = acpi_ghes_memory_errors(ags, ACPI_HEST_SRC_ID_SYNC,
+                                  addresses, num_of_addresses, errp);
+    kvm_inject_arm_sea(c);
+
+    return ret;
+}
+
 void kvm_arch_on_sigbus_vcpu(CPUState *c, int code, void *addr)
 {
     ram_addr_t ram_addr;
     hwaddr paddr;
     AcpiGhesState *ags;
-    uint64_t addresses[16];
 
     assert(code == BUS_MCEERR_AR || code == BUS_MCEERR_AO);
 
@@ -2455,12 +2517,8 @@ void kvm_arch_on_sigbus_vcpu(CPUState *c, int code, void *addr)
              * later from the main thread, so doing the injection of
              * the error would be more complicated.
              */
-            addresses[0] = paddr;
             if (code == BUS_MCEERR_AR) {
-                kvm_cpu_synchronize_state(c);
-                acpi_ghes_memory_errors(ags, ACPI_HEST_SRC_ID_SYNC,
-                                        addresses, 1, &error_fatal);
-                kvm_inject_arm_sea(c);
+                push_ghes_memory_errors(c, ags, paddr, &error_fatal);
             }
             return;
         }
-- 
2.51.1



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

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-12 17:25 [PATCH v4 0/8] target/arm/kvm: Improve memory error handling Gavin Shan
2025-11-12 17:25 ` [PATCH v4 1/8] acpi/ghes: Make GHES max raw data length dynamic Gavin Shan
2025-11-12 17:25 ` [PATCH v4 2/8] tests/qtest/bios-tables-test: Prepare for changes in the HEST table Gavin Shan
2025-11-12 17:25 ` [PATCH v4 3/8] acpi/ghes: Increase GHES raw data maximal length to 4KiB Gavin Shan
2025-11-12 17:25 ` [PATCH v4 4/8] tests/qtest/bios-tables-test: Update HEST table Gavin Shan
2025-11-12 17:25 ` [PATCH v4 5/8] acpi/ghes: Extend acpi_ghes_memory_errors() for multiple CPERs Gavin Shan
2025-11-12 17:25 ` [PATCH v4 6/8] acpi/ghes: Bail early on error from get_ghes_source_offsets() Gavin Shan
2025-11-12 17:25 ` [PATCH v4 7/8] acpi/ghes: Use error_fatal in acpi_ghes_memory_errors() Gavin Shan
2025-11-13  7:41   ` Markus Armbruster
2025-11-14  9:46     ` Gavin Shan
2025-11-12 17:25 ` Gavin Shan [this message]
2025-11-18 10:47 ` [PATCH v4 0/8] target/arm/kvm: Improve memory error handling Jonathan Cameron via
2025-11-18 10:54   ` Mauro Carvalho Chehab
2025-11-21  6:54     ` Gavin Shan
2025-11-21  6:51   ` Gavin Shan

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=20251112172535.403042-9-gshan@redhat.com \
    --to=gshan@redhat.com \
    --cc=anisinha@redhat.com \
    --cc=armbru@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=gengdongjiu1@gmail.com \
    --cc=imammedo@redhat.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mchehab+huawei@kernel.org \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=shan.gavin@gmail.com \
    --cc=wangyanan55@huawei.com \
    --cc=zhao1.liu@intel.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).