All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukas Wunner <lukas@wunner.de>
To: Matt Fleming <matt@codeblueprint.co.uk>
Cc: linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
	Andreas Noever <andreas.noever@gmail.com>,
	x86@kernel.org
Subject: Re: [PATCH 0/6] Apple device properties
Date: Mon, 22 Aug 2016 11:58:50 +0200	[thread overview]
Message-ID: <20160822095850.GA22131@wunner.de> (raw)
In-Reply-To: <20160818203433.GP30909@codeblueprint.co.uk>

On Thu, Aug 18, 2016 at 09:34:33PM +0100, Matt Fleming wrote:
> On Mon, 15 Aug, at 06:13:58PM, Lukas Wunner wrote:
> > But I would like to understand the "cannot jump through pointers at
> > runtime" argument because the binary code looks to me like it should
> > work on 32 bit. I guess I must be missing something obvious?
> 
> Ah no, I forgot that efi_boot_services_{32,64}_t doesn't contain
> pointers - it contains u32/u64 objects. So yeah, your patch looks
> fine.
> 
> It does trigger the following warnings when building for i386 though,
> 
> In file included from /dev/shm/mfleming/git/efi/drivers/firmware/efi/libstub/efi-stub-helper.c:14:0:
> /dev/shm/mfleming/git/efi/drivers/firmware/efi/libstub/efi-stub-helper.c: In function ???efi_get_memory_map???:
> /dev/shm/mfleming/git/efi/arch/x86/include/asm/efi.h:205:3: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
>   ((efi_boot_services_64_t *)__efi_early()->boot_services)->f : \
>    ^

Right, sorry, I didn't compile-test that version on x86_32.

I'm sending out a new version now which compiles cleanly in all three
cases (x86_32, x86_64 with and without mixed-mode), works fine on my
64-bit EFI and the 32-bit code at least *looks* okay when disassembled.

By the way, arch/x86/Kconfig says that "it is not possible to boot a
mixed-mode enabled kernel via the EFI boot stub - a bootloader that
supports the EFI handover protocol must be used".

Is this still correct? With all the mixed-mode support in head_64.S
and eboot.c, I'm wondering what's missing?

Thanks,

Lukas

WARNING: multiple messages have this Message-ID (diff)
From: Lukas Wunner <lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org>
To: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Andreas Noever
	<andreas.noever-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
Subject: Re: [PATCH 0/6] Apple device properties
Date: Mon, 22 Aug 2016 11:58:50 +0200	[thread overview]
Message-ID: <20160822095850.GA22131@wunner.de> (raw)
In-Reply-To: <20160818203433.GP30909-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>

On Thu, Aug 18, 2016 at 09:34:33PM +0100, Matt Fleming wrote:
> On Mon, 15 Aug, at 06:13:58PM, Lukas Wunner wrote:
> > But I would like to understand the "cannot jump through pointers at
> > runtime" argument because the binary code looks to me like it should
> > work on 32 bit. I guess I must be missing something obvious?
> 
> Ah no, I forgot that efi_boot_services_{32,64}_t doesn't contain
> pointers - it contains u32/u64 objects. So yeah, your patch looks
> fine.
> 
> It does trigger the following warnings when building for i386 though,
> 
> In file included from /dev/shm/mfleming/git/efi/drivers/firmware/efi/libstub/efi-stub-helper.c:14:0:
> /dev/shm/mfleming/git/efi/drivers/firmware/efi/libstub/efi-stub-helper.c: In function ???efi_get_memory_map???:
> /dev/shm/mfleming/git/efi/arch/x86/include/asm/efi.h:205:3: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
>   ((efi_boot_services_64_t *)__efi_early()->boot_services)->f : \
>    ^

Right, sorry, I didn't compile-test that version on x86_32.

I'm sending out a new version now which compiles cleanly in all three
cases (x86_32, x86_64 with and without mixed-mode), works fine on my
64-bit EFI and the 32-bit code at least *looks* okay when disassembled.

By the way, arch/x86/Kconfig says that "it is not possible to boot a
mixed-mode enabled kernel via the EFI boot stub - a bootloader that
supports the EFI handover protocol must be used".

Is this still correct? With all the mixed-mode support in head_64.S
and eboot.c, I'm wondering what's missing?

Thanks,

Lukas

  reply	other threads:[~2016-08-22  9:57 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-27 11:20 [PATCH 0/6] Apple device properties Lukas Wunner
2016-07-27 11:20 ` Lukas Wunner
2016-07-27 11:20 ` [PATCH 1/6] efi: Retrieve " Lukas Wunner
2016-07-27 11:20   ` Lukas Wunner
2016-07-30 19:16   ` Andrei Borzenkov
2016-07-30 19:16     ` Andrei Borzenkov
2016-08-04 15:13   ` Matt Fleming
2016-08-04 15:13     ` Matt Fleming
     [not found]     ` <20160804151345.GM3636-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2016-08-05 11:42       ` Lukas Wunner
2016-08-05 11:42         ` Lukas Wunner
2016-08-05 12:06         ` Matt Fleming
2016-07-27 11:20 ` [PATCH 6/6] thunderbolt: Use Device ROM retrieved from EFI Lukas Wunner
2016-07-27 11:20 ` [PATCH 3/6] efi: Add device path parser Lukas Wunner
2016-07-27 11:20 ` [PATCH 5/6] efi: Assign Apple device properties Lukas Wunner
     [not found]   ` <a0edd928ab099682c2cb4c4544c599573144d03a.1469616641.git.lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org>
2016-08-04 15:52     ` Matt Fleming
2016-08-04 15:52       ` Matt Fleming
2016-07-27 11:20 ` [PATCH 2/6] ACPI / bus: Make acpi_get_first_physical_node() public Lukas Wunner
2016-08-17  0:38   ` Rafael J. Wysocki
     [not found]     ` <1821462.QyPXGhZaWJ-sKB8Sp2ER+y1GS7QM15AGw@public.gmane.org>
2016-09-12 22:03       ` Rafael J. Wysocki
2016-09-12 22:03         ` Rafael J. Wysocki
2016-07-27 11:20 ` [PATCH 4/6] driver core: Don't leak secondary fwnode on device removal Lukas Wunner
2016-07-27 11:20   ` Lukas Wunner
2016-08-17  0:38   ` Rafael J. Wysocki
2016-08-30  9:03     ` Lukas Wunner
2016-09-12 22:03       ` Rafael J. Wysocki
2016-07-27 23:48 ` [PATCH 0/6] Apple device properties Rafael J. Wysocki
2016-07-27 23:48   ` Rafael J. Wysocki
2016-07-28  0:25 ` [PATCH 5/6] efi: Assign " Lukas Wunner
2016-07-28  0:25 ` [PATCH 2/6] ACPI / bus: Make acpi_get_first_physical_node() public Lukas Wunner
2016-07-28  0:25 ` [PATCH 4/6] driver core: Don't leak secondary fwnode on device removal Lukas Wunner
2016-07-28  0:25 ` [PATCH 1/6] efi: Retrieve Apple device properties Lukas Wunner
2016-07-28  0:25 ` [PATCH 6/6] thunderbolt: Use Device ROM retrieved from EFI Lukas Wunner
2016-07-28  0:25 ` [PATCH 3/6] efi: Add device path parser Lukas Wunner
2016-08-04 14:57 ` [PATCH 0/6] Apple device properties Matt Fleming
2016-08-09 13:38   ` Lukas Wunner
2016-08-15 11:54     ` Matt Fleming
2016-08-15 16:13       ` Lukas Wunner
2016-08-18 20:34         ` Matt Fleming
2016-08-22  9:58           ` Lukas Wunner [this message]
2016-08-22  9:58             ` Lukas Wunner
2016-08-24 19:49             ` Matt Fleming
2016-07-28  0:25 Lukas Wunner

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=20160822095850.GA22131@wunner.de \
    --to=lukas@wunner.de \
    --cc=andreas.noever@gmail.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt@codeblueprint.co.uk \
    --cc=x86@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.