Re: [PATCH v6 1/3] x86/boot: Add acpitb.c to parse acpi tables

On Mon, Sep 10, 2018 at 10:13:49PM +0200, Rafael J. Wysocki wrote: >On Mon, Sep 10, 2018 at 2:41 PM Chao Fan wrote: >> >> Imitate the ACPI code of parsing ACPI tables to dig and read ACPI >> tables. > >Why? Sorry for that, I have sent the cover letter to you. > >> Since some operations are not

Random crashes with i386 and efi boots

Hi folks, even after commit eeb89e2bb1ac ("x86/efi: Load fixmap GDT in efi_call_phys_epilog()"), my i386/efi qemu boot tests still crash randomly (roughly 5-10% of the time). As before, I don't see much useful output in the qemu log (this time it doesn't even complain about a triple fault).

Re: [PATCH v6 1/3] x86/boot: Add acpitb.c to parse acpi tables

On Mon, Sep 10, 2018 at 2:41 PM Chao Fan wrote: > > Imitate the ACPI code of parsing ACPI tables to dig and read ACPI > tables. Why? > Since some operations are not needed here, What operations? > functions are simplified. Functions will be used to dig SRAT tables to get > information of

RE: [PATCH V5 0/2] Add efi page fault handler to recover from page

Hi All, > Changes from V4 to V5: > -- > 1. Drop config option that enables efi page fault handler, instead make >it default. > 2. Call schedule() in an infinite loop to account for spurious wake ups. > 3. Introduce "NONE" as an efi runtime service function identifier so

[PATCH V5 2/2] x86/efi: Add efi page fault handler to recover from page faults caused by the firmware

From: Sai Praneeth As per the UEFI specification, after the call to ExitBootServices(), accesses by the firmware to any memory regions except EFI_RUNTIME_SERVICES_ regions is considered illegal. A buggy firmware could trigger these illegal accesses when an efi runtime service is invoked and if

[PATCH V5 0/2] Add efi page fault handler to recover from page

From: Sai Praneeth There may exist some buggy UEFI firmware implementations that access efi memory regions other than EFI_RUNTIME_SERVICES_ even after the kernel has assumed control of the platform. This violates UEFI specification. Hence, provide a efi specific page fault handler which recovers

[PATCH V5 1/2] efi: Make efi_rts_work accessible to efi page fault handler

From: Sai Praneeth After the kernel has booted, if any accesses by firmware causes a page fault, the efi page fault handler would freeze efi_rts_wq and schedules a new process. To do this, the efi page fault handler needs efi_rts_work. Hence, make it accessible. There will be no race conditions

Re: [PATCH] efi: take size of partition entry from GPT header

On 10 September 2018 at 21:03, Eugene Korenevsky wrote: > Use gpt_header.sizeof_partition_entry instead of sizeof(gpt_entry) > for GPT entry size. > According to UEFI spec, GPT entry size is specified in GPT header. > I think this patch is probably correct, but could you please provide more

[PATCH] efi: take size of partition entry from GPT header

Use gpt_header.sizeof_partition_entry instead of sizeof(gpt_entry) for GPT entry size. According to UEFI spec, GPT entry size is specified in GPT header. Signed-off-by: Eugene Korenevsky --- block/partitions/efi.c | 26 -- 1 file changed, 12 insertions(+), 14

[PATCH v6 1/3] x86/boot: Add acpitb.c to parse acpi tables

Imitate the ACPI code of parsing ACPI tables to dig and read ACPI tables. Since some operations are not needed here, functions are simplified. Functions will be used to dig SRAT tables to get information of memory, so that KASLR can the memory in immovable node. And also, these functions won't

Re: [PATCH] x86/efi: earlyprintk - Add 64bit efi fb address support

* Aaron Ma wrote: > if (efi_fb) > return (efi_fb + start); Just noticed this detail unrelated to your patch: return is not a function. Thanks, Ingo