[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v15 10/10] target-arm: kvm64: handle SIGBUS sign
From: |
gengdongjiu |
Subject: |
Re: [Qemu-devel] [PATCH v15 10/10] target-arm: kvm64: handle SIGBUS signal from kernel or KVM |
Date: |
Thu, 10 Jan 2019 15:36:57 +0000 |
>
> On Thu, 8 Nov 2018 at 10:18, Dongjiu Geng <address@hidden> wrote:
> >
> > Add SIGBUS signal handler. In this handler, it checks the SIGBUS type,
> > translates the host VA delivered by host to guest PA, then fill this
> > PA to guest APEI GHES memory, then notify guest according to the SIGBUS
> > type.
> > There are two kinds of SIGBUS that QEMU needs to handle, which are
> > BUS_MCEERR_AO and BUS_MCEERR_AR.
>
> > +bool ghes_record_errors(uint32_t notify, uint64_t physical_address) {
> > + uint64_t error_block_addr, read_ack_register_addr;
> > + int read_ack_register = 0, loop = 0;
> > + uint64_t start_addr = le32_to_cpu(ges.ghes_addr_le);
> > + bool ret = GHES_CPER_FAIL;
> > + const uint8_t error_source_id[] = { 0xff, 0xff, 0xff, 0xff,
> > + 0xff, 0xff, 0xff, 0, 1};
> > +
> > + /*
> > + * | +---------------------+ ges.ghes_addr_le
> > + * | |error_block_address0|
> > + * | +---------------------+
> > + * | |error_block_address1|
> > + * | +---------------------+ --+--
> > + * | | ............. | GHES_ADDRESS_SIZE
> > + * | +---------------------+ --+--
> > + * | |error_block_addressN|
> > + * | +---------------------+
> > + * | | read_ack_register0 |
> > + * | +---------------------+ --+--
> > + * | | read_ack_register1 | GHES_ADDRESS_SIZE
> > + * | +---------------------+ --+--
> > + * | | ............. |
> > + * | +---------------------+
> > + * | | read_ack_registerN |
> > + * | +---------------------+ --+--
> > + * | | CPER | |
> > + * | | .... | GHES_MAX_RAW_DATA_LENGT
> > + * | | CPER | |
> > + * | +---------------------+ --+--
> > + * | | .......... |
> > + * | +---------------------+
> > + * | | CPER |
> > + * | | .... |
> > + * | | CPER |
> > + * | +---------------------+
> > + */
> > + if (physical_address && notify < ACPI_HEST_NOTIFY_RESERVED) {
>
> Why is a zero physical address special here? Shouldn't we be able to report
> "the memory backing physaddr 0 has a fault" ?
Thanks a lot for the reminder, the physical memory address 0 can also have a
fault. It should not a special address.
>
> thanks
> -- PMM