Hi Eugene,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on block/for-next]
[also build test ERROR on v4.19-rc3 next-20180911]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
On 11 September 2018 at 18:15, Eugene Korenevsky wrote:
> Use gpt_header.sizeof_partition_entry instead of sizeof(gpt_entry)
> for GPT entry size.
> According to UEFI 2.7 spec 5.3.1 "GPT overview":, the size of a GUID Partition
> Entry element is defined in the Size Of Partition Entry field of GPT
Hi Eugene,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on block/for-next]
[also build test ERROR on v4.19-rc3 next-20180911]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
Default EFI_ARMSTUB_DTB_LOADER to y to allow the dtb= command
line parameter to function with efi loader.
Required for development purposes and to boot on existing bootloaders
that do not support devicetree provided by the platform or by the bootloader.
Fixes: 3d7ee348aa41 ("efi/libstub/arm: Add
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
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 th
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
On Tue, Sep 11, 2018 at 11:05:25AM -0700, Andy Lutomirski wrote:
>
>
> > On Sep 11, 2018, at 10:41 AM, Joerg Roedel wrote:
> >
> > On Tue, Sep 11, 2018 at 09:36:51AM -0700, Andy Lutomirski wrote:
> >>> save_pgd = efi_call_phys_prolog();
> >>> local_irq_save(flags);
> >>> status = efi_call
Commit eeb89e2bb1ac ("x86/efi: Load fixmap GDT in efi_call_phys_epilog()")
moved loading the fixmap in efi_call_phys_epilog() after load_cr3()
since it was assumed to be more logical.
Turns out this is incorrect: In efi_call_phys_prolog(), we load the gdt
with its physical address, and when we rel
> On Sep 11, 2018, at 10:41 AM, Joerg Roedel wrote:
>
> On Tue, Sep 11, 2018 at 09:36:51AM -0700, Andy Lutomirski wrote:
>>> save_pgd = efi_call_phys_prolog();
>>> local_irq_save(flags);
>>> status = efi_call_phys(...);
>>> local_irq_restore(flags);
>>>
>>> efi_call_phys_epi
On Tue, Sep 11, 2018 at 07:41:58PM +0200, Joerg Roedel wrote:
> On Tue, Sep 11, 2018 at 09:36:51AM -0700, Andy Lutomirski wrote:
> > >save_pgd = efi_call_phys_prolog();
> > >local_irq_save(flags);
> > >status = efi_call_phys(...);
> > >local_irq_restore(flags);
> > >
> > >
On Tue, Sep 11, 2018 at 7:42 AM Joerg Roedel wrote:
>
> So I am in favor of changing the order in efi_call_phys_epilog() too.
Yeah, the only reason the order was changed was that it seemed more
logical to use the new cr3 to load the GDT. But that was clearly
wrong.
So ack on just changing the or
On Tue, Sep 11, 2018 at 09:36:51AM -0700, Andy Lutomirski wrote:
> >save_pgd = efi_call_phys_prolog();
> >local_irq_save(flags);
> >status = efi_call_phys(...);
> >local_irq_restore(flags);
> >
> >efi_call_phys_epilog(save_pgd);
> >
> > So, yes, interrupts are very muc
> >The GPT with entries sized more than sizeof(gpt_entry) is not illegal.
> >OVMF firmware from EDK2 perfectly works with it, see edk2-tianocore source
> >code.
> But _why_ is this needed? Does this firmware need larger sized entries (ie:
> does
> not work without it)?
A disk with correct large-
> On Sep 11, 2018, at 6:30 AM, Guenter Roeck wrote:
>
> On 09/11/2018 04:52 AM, Andy Lutomirski wrote:
>>> On Sep 10, 2018, at 2:56 PM, Guenter Roeck wrote:
>>>
>>> Hi folks,
>>>
>>> even after commit eeb89e2bb1ac ("x86/efi: Load fixmap GDT in
>>> efi_call_phys_epilog()"), my i386/efi qemu
On Tue, 11 Sep 2018, Eugene Korenevsky wrote:
Use gpt_header.sizeof_partition_entry instead of sizeof(gpt_entry)
for GPT entry size.
According to UEFI 2.7 spec 5.3.1 "GPT overview":, the size of a GUID Partition
Entry element is defined in the Size Of Partition Entry field of GPT header.
The GPT
Use gpt_header.sizeof_partition_entry instead of sizeof(gpt_entry)
for GPT entry size.
According to UEFI 2.7 spec 5.3.1 "GPT overview":, the size of a GUID Partition
Entry element is defined in the Size Of Partition Entry field of GPT header.
The GPT with entries sized more than sizeof(gpt_entry) i
On 09/11/2018 04:52 AM, Andy Lutomirski wrote:
On Sep 10, 2018, at 2:56 PM, Guenter Roeck wrote:
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
> On Sep 10, 2018, at 2:56 PM, Guenter Roeck wrote:
>
> 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 qem
On Friday, August 31, 2018 11:10:17 AM CEST Andy Shevchenko wrote:
> Replace custom grown macro with generic INTEL_CPU_FAM6_NODATA() one.
>
> No functional change intended.
>
> Signed-off-by: Andy Shevchenko
> ---
> drivers/acpi/acpi_lpss.c | 6 ++
> 1 file changed, 2 insertions(+), 4 delet
On Friday, August 31, 2018 11:10:18 AM CEST Andy Shevchenko wrote:
> Replace custom grown macro with generic INTEL_CPU_FAM6_NODATA() one.
>
> No functional change intended.
>
> Signed-off-by: Andy Shevchenko
> ---
> drivers/acpi/x86/utils.c | 18 --
> 1 file changed, 8 insertion
On Tue, Sep 11, 2018 at 04:52:26PM +0800, kbuild test robot wrote:
>
>Fixes: cc1a4e2a5474 ("x86/boot: Add acpitb.c to parse acpi tables")
>Signed-off-by: kbuild test robot
>---
> acpitb.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/arch/x86/boot/compressed/acpitb.c
>
Fixes: cc1a4e2a5474 ("x86/boot: Add acpitb.c to parse acpi tables")
Signed-off-by: kbuild test robot
---
acpitb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/boot/compressed/acpitb.c
b/arch/x86/boot/compressed/acpitb.c
index 66c5154..4ddd732 100644
--- a/arc
/linux/commits/Chao-Fan/x86-boot-KASLR-Parse-ACPI-table-and-limit-kaslr-in-immovable-memory/20180911-043350
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All
-Praneeth-Prakhya/efi-Make-efi_rts_work-accessible-to-efi-page-fault-handler/20180911-14
base: https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git next
config: i386-alldefconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to
-Praneeth-Prakhya/efi-Make-efi_rts_work-accessible-to-efi-page-fault-handler/20180911-14
base: https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git next
config: i386-randconfig-s0-201836 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the
On Tue, Sep 11, 2018 at 09:41:36AM +0200, Rafael J. Wysocki wrote:
>On Tue, Sep 11, 2018 at 3:28 AM Chao Fan wrote:
>>
>> 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
On Tue, Sep 11, 2018 at 3:28 AM Chao Fan wrote:
>
> 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
28 matches
Mail list logo
