[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v19 5/5] target-arm: kvm64: handle SIGBUS signal from kernel
From: |
Peter Maydell |
Subject: |
Re: [PATCH v19 5/5] target-arm: kvm64: handle SIGBUS signal from kernel or KVM |
Date: |
Tue, 15 Oct 2019 15:48:53 +0100 |
On Tue, 15 Oct 2019 at 15:02, Xiang Zheng <address@hidden> wrote:
>
> From: Dongjiu Geng <address@hidden>
>
> Add a SIGBUS signal handler. In this handler, it checks the SIGBUS type,
> translates the host VA delivered by host to guest PA, then fills this PA
> to guest APEI GHES memory, then notifies guest according to the SIGBUS
> type.
>
> When guest accesses the poisoned memory, it will generate a Synchronous
> External Abort(SEA). Then host kernel gets an APEI notification and calls
> memory_failure() to unmapped the affected page in stage 2, finally
> returns to guest.
>
> Guest continues to access the PG_hwpoison page, it will trap to KVM as
> stage2 fault, then a SIGBUS_MCEERR_AR synchronous signal is delivered to
> Qemu, Qemu records this error address into guest APEI GHES memory and
> notifes guest using Synchronous-External-Abort(SEA).
>
> In order to inject a vSEA, we introduce the kvm_inject_arm_sea() function
> in which we can setup the type of exception and the syndrome information.
> When switching to guest, the target vcpu will jump to the synchronous
> external abort vector table entry.
>
> The ESR_ELx.DFSC is set to synchronous external abort(0x10), and the
> ESR_ELx.FnV is set to not valid(0x1), which will tell guest that FAR is
> not valid and hold an UNKNOWN value. These values will be set to KVM
> register structures through KVM_SET_ONE_REG IOCTL.
>
> Signed-off-by: Dongjiu Geng <address@hidden>
> Signed-off-by: Xiang Zheng <address@hidden>
> +static int acpi_ghes_record_mem_error(uint64_t error_block_address,
> + uint64_t error_physical_addr,
> + uint32_t data_length)
> +{
> + GArray *block;
> + uint64_t current_block_length;
> + /* Memory Error Section Type */
> + QemuUUID mem_section_id_le = UEFI_CPER_SEC_PLATFORM_MEM;
> + QemuUUID fru_id = {0};
Hi; this makes at least some versions of clang complain
(this is a clang bug, but it's present in shipped versions):
/home/petmay01/linaro/qemu-from-laptop/qemu/hw/acpi/acpi_ghes.c:135:24:
error: suggest braces around
initialization of subobject [-Werror,-Wmissing-braces]
QemuUUID fru_id = {0};
^
{}
We generally use "{}" as the generic zero-initializer for
this reason (it's gcc/clang specific whereas "{0}" is
in the standard, but all of the compilers we care about
support it and don't warn about its use).
> + uint8_t fru_text[20] = {0};
Clang doesn't mind this one because it's not initializing
a struct type, but you could use "{}" here too for consistency.
thanks
-- PMM
- [PATCH v19 0/5] Add ARMv8 RAS virtualization support in QEMU, Xiang Zheng, 2019/10/15
- [PATCH v19 1/5] hw/arm/virt: Introduce a RAS machine option, Xiang Zheng, 2019/10/15
- [PATCH v19 2/5] docs: APEI GHES generation and CPER record description, Xiang Zheng, 2019/10/15
- [PATCH v19 4/5] KVM: Move hwpoison page related functions into kvm-all.c, Xiang Zheng, 2019/10/15
- [PATCH v19 3/5] ACPI: Add APEI GHES table generation support, Xiang Zheng, 2019/10/15
- [PATCH v19 5/5] target-arm: kvm64: handle SIGBUS signal from kernel or KVM, Xiang Zheng, 2019/10/15
- Re: [PATCH v19 5/5] target-arm: kvm64: handle SIGBUS signal from kernel or KVM,
Peter Maydell <=
- Re: [PATCH v19 0/5] Add ARMv8 RAS virtualization support in QEMU, no-reply, 2019/10/15