<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/include/linux/efi.h, branch v3.15.4</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>Merge remote-tracking branch 'tip/x86/efi-mixed' into efi-for-mingo</title>
<updated>2014-03-05T18:15:37+00:00</updated>
<author>
<name>Matt Fleming</name>
<email>matt.fleming@intel.com</email>
</author>
<published>2014-03-05T18:15:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=994448f1afa6689bafbebaf7412b23b541b41ef5'/>
<id>994448f1afa6689bafbebaf7412b23b541b41ef5</id>
<content type='text'>
Conflicts:
	arch/x86/kernel/setup.c
	arch/x86/platform/efi/efi.c
	arch/x86/platform/efi/efi_64.c
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Conflicts:
	arch/x86/kernel/setup.c
	arch/x86/platform/efi/efi.c
	arch/x86/platform/efi/efi_64.c
</pre>
</div>
</content>
</entry>
<entry>
<title>efi: Add separate 32-bit/64-bit definitions</title>
<updated>2014-03-04T21:25:02+00:00</updated>
<author>
<name>Matt Fleming</name>
<email>matt.fleming@intel.com</email>
</author>
<published>2014-01-10T13:47:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=677703cef0a148ba07d37ced649ad25b1cda2f78'/>
<id>677703cef0a148ba07d37ced649ad25b1cda2f78</id>
<content type='text'>
The traditional approach of using machine-specific types such as
'unsigned long' does not allow the kernel to interact with firmware
running in a different CPU mode, e.g. 64-bit kernel with 32-bit EFI.

Add distinct EFI structure definitions for both 32-bit and 64-bit so
that we can use them in the 32-bit and 64-bit code paths.

Acked-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The traditional approach of using machine-specific types such as
'unsigned long' does not allow the kernel to interact with firmware
running in a different CPU mode, e.g. 64-bit kernel with 32-bit EFI.

Add distinct EFI structure definitions for both 32-bit and 64-bit so
that we can use them in the 32-bit and 64-bit code paths.

Acked-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ia64/efi: Implement efi_enabled()</title>
<updated>2014-03-04T16:17:20+00:00</updated>
<author>
<name>Matt Fleming</name>
<email>matt.fleming@intel.com</email>
</author>
<published>2014-01-15T13:49:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=092063808c498eccac8e891973bf143e7b60d723'/>
<id>092063808c498eccac8e891973bf143e7b60d723</id>
<content type='text'>
There's no good reason to keep efi_enabled() under CONFIG_X86 anymore,
since nothing about the implementation is specific to x86.

Set EFI feature flags in the ia64 boot path instead of claiming to
support all features. The old behaviour was actually buggy since
efi.memmap never points to a valid memory map, so we shouldn't be
claiming to support EFI_MEMMAP.

Fortunately, this bug was never triggered because EFI_MEMMAP isn't used
outside of arch/x86 currently, but that may not always be the case.

Reviewed-and-tested-by: Tony Luck &lt;tony.luck@intel.com&gt;
Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There's no good reason to keep efi_enabled() under CONFIG_X86 anymore,
since nothing about the implementation is specific to x86.

Set EFI feature flags in the ia64 boot path instead of claiming to
support all features. The old behaviour was actually buggy since
efi.memmap never points to a valid memory map, so we shouldn't be
claiming to support EFI_MEMMAP.

Fortunately, this bug was never triggered because EFI_MEMMAP isn't used
outside of arch/x86 currently, but that may not always be the case.

Reviewed-and-tested-by: Tony Luck &lt;tony.luck@intel.com&gt;
Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi: Move facility flags to struct efi</title>
<updated>2014-03-04T16:16:16+00:00</updated>
<author>
<name>Matt Fleming</name>
<email>matt.fleming@intel.com</email>
</author>
<published>2014-01-15T13:21:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3e909599215456928e6b42a04f11c2517881570b'/>
<id>3e909599215456928e6b42a04f11c2517881570b</id>
<content type='text'>
As we grow support for more EFI architectures they're going to want the
ability to query which EFI features are available on the running system.
Instead of storing this information in an architecture-specific place,
stick it in the global 'struct efi', which is already the central
location for EFI state.

While we're at it, let's change the return value of efi_enabled() to be
bool and replace all references to 'facility' with 'feature', which is
the usual word used to describe the attributes of the running system.

Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
As we grow support for more EFI architectures they're going to want the
ability to query which EFI features are available on the running system.
Instead of storing this information in an architecture-specific place,
stick it in the global 'struct efi', which is already the central
location for EFI state.

While we're at it, let's change the return value of efi_enabled() to be
bool and replace all references to 'facility' with 'feature', which is
the usual word used to describe the attributes of the running system.

Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'v3.13-rc7' into x86/efi-kexec to resolve conflicts</title>
<updated>2014-01-05T11:34:29+00:00</updated>
<author>
<name>Ingo Molnar</name>
<email>mingo@kernel.org</email>
</author>
<published>2014-01-05T11:34:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ef0b8b9a521c65201bfca9747ee1bf374296133c'/>
<id>ef0b8b9a521c65201bfca9747ee1bf374296133c</id>
<content type='text'>
Conflicts:
	arch/x86/platform/efi/efi.c
	drivers/firmware/efi/Kconfig

Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Conflicts:
	arch/x86/platform/efi/efi.c
	drivers/firmware/efi/Kconfig

Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi: Export EFI runtime memory mapping to sysfs</title>
<updated>2013-12-21T15:29:36+00:00</updated>
<author>
<name>Dave Young</name>
<email>dyoung@redhat.com</email>
</author>
<published>2013-12-20T10:02:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=926172d46038d7610b6b8d84e40db727cefb482d'/>
<id>926172d46038d7610b6b8d84e40db727cefb482d</id>
<content type='text'>
kexec kernel will need exactly same mapping for EFI runtime memory
ranges. Thus here export the runtime ranges mapping to sysfs,
kexec-tools will assemble them and pass to 2nd kernel via setup_data.

Introducing a new directory /sys/firmware/efi/runtime-map just like
/sys/firmware/memmap. Containing below attribute in each file of that
directory:

attribute  num_pages  phys_addr  type  virt_addr

Signed-off-by: Dave Young &lt;dyoung@redhat.com&gt;
Tested-by: Toshi Kani &lt;toshi.kani@hp.com&gt;
Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
kexec kernel will need exactly same mapping for EFI runtime memory
ranges. Thus here export the runtime ranges mapping to sysfs,
kexec-tools will assemble them and pass to 2nd kernel via setup_data.

Introducing a new directory /sys/firmware/efi/runtime-map just like
/sys/firmware/memmap. Containing below attribute in each file of that
directory:

attribute  num_pages  phys_addr  type  virt_addr

Signed-off-by: Dave Young &lt;dyoung@redhat.com&gt;
Tested-by: Toshi Kani &lt;toshi.kani@hp.com&gt;
Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi: Export more EFI table variables to sysfs</title>
<updated>2013-12-21T15:29:36+00:00</updated>
<author>
<name>Dave Young</name>
<email>dyoung@redhat.com</email>
</author>
<published>2013-12-20T10:02:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a0998eb15afeffbf52a2c2829318f67df9ac57b8'/>
<id>a0998eb15afeffbf52a2c2829318f67df9ac57b8</id>
<content type='text'>
Export fw_vendor, runtime and config table physical addresses to
/sys/firmware/efi/{fw_vendor,runtime,config_table} because kexec kernels
need them.

From EFI spec these 3 variables will be updated to virtual address after
entering virtual mode. But kernel startup code will need the physical
address.

Signed-off-by: Dave Young &lt;dyoung@redhat.com&gt;
Tested-by: Toshi Kani &lt;toshi.kani@hp.com&gt;
Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Export fw_vendor, runtime and config table physical addresses to
/sys/firmware/efi/{fw_vendor,runtime,config_table} because kexec kernels
need them.

From EFI spec these 3 variables will be updated to virtual address after
entering virtual mode. But kernel startup code will need the physical
address.

Signed-off-by: Dave Young &lt;dyoung@redhat.com&gt;
Tested-by: Toshi Kani &lt;toshi.kani@hp.com&gt;
Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efivars, efi-pstore: Hold off deletion of sysfs entry until the scan is completed</title>
<updated>2013-11-28T20:16:55+00:00</updated>
<author>
<name>Seiji Aguchi</name>
<email>seiji.aguchi@hds.com</email>
</author>
<published>2013-10-30T19:27:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e0d59733f6b1796b8d6692642c87d7dd862c3e3a'/>
<id>e0d59733f6b1796b8d6692642c87d7dd862c3e3a</id>
<content type='text'>
Currently, when mounting pstore file system, a read callback of
efi_pstore driver runs mutiple times as below.

- In the first read callback, scan efivar_sysfs_list from head and pass
  a kmsg buffer of a entry to an upper pstore layer.
- In the second read callback, rescan efivar_sysfs_list from the entry
  and pass another kmsg buffer to it.
- Repeat the scan and pass until the end of efivar_sysfs_list.

In this process, an entry is read across the multiple read function
calls. To avoid race between the read and erasion, the whole process
above is protected by a spinlock, holding in open() and releasing in
close().

At the same time, kmemdup() is called to pass the buffer to pstore
filesystem during it. And then, it causes a following lockdep warning.

To make the dynamic memory allocation runnable without taking spinlock,
holding off a deletion of sysfs entry if it happens while scanning it
via efi_pstore, and deleting it after the scan is completed.

To implement it, this patch introduces two flags, scanning and deleting,
to efivar_entry.

On the code basis, it seems that all the scanning and deleting logic is
not needed because __efivars-&gt;lock are not dropped when reading from the
EFI variable store.

But, the scanning and deleting logic is still needed because an
efi-pstore and a pstore filesystem works as follows.

In case an entry(A) is found, the pointer is saved to psi-&gt;data.  And
efi_pstore_read() passes the entry(A) to a pstore filesystem by
releasing  __efivars-&gt;lock.

And then, the pstore filesystem calls efi_pstore_read() again and the
same entry(A), which is saved to psi-&gt;data, is used for resuming to scan
a sysfs-list.

So, to protect the entry(A), the logic is needed.

[    1.143710] ------------[ cut here ]------------
[    1.144058] WARNING: CPU: 1 PID: 1 at kernel/lockdep.c:2740 lockdep_trace_alloc+0x104/0x110()
[    1.144058] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
[    1.144058] Modules linked in:
[    1.144058] CPU: 1 PID: 1 Comm: systemd Not tainted 3.11.0-rc5 #2
[    1.144058]  0000000000000009 ffff8800797e9ae0 ffffffff816614a5 ffff8800797e9b28
[    1.144058]  ffff8800797e9b18 ffffffff8105510d 0000000000000080 0000000000000046
[    1.144058]  00000000000000d0 00000000000003af ffffffff81ccd0c0 ffff8800797e9b78
[    1.144058] Call Trace:
[    1.144058]  [&lt;ffffffff816614a5&gt;] dump_stack+0x54/0x74
[    1.144058]  [&lt;ffffffff8105510d&gt;] warn_slowpath_common+0x7d/0xa0
[    1.144058]  [&lt;ffffffff8105517c&gt;] warn_slowpath_fmt+0x4c/0x50
[    1.144058]  [&lt;ffffffff8131290f&gt;] ? vsscanf+0x57f/0x7b0
[    1.144058]  [&lt;ffffffff810bbd74&gt;] lockdep_trace_alloc+0x104/0x110
[    1.144058]  [&lt;ffffffff81192da0&gt;] __kmalloc_track_caller+0x50/0x280
[    1.144058]  [&lt;ffffffff815147bb&gt;] ? efi_pstore_read_func.part.1+0x12b/0x170
[    1.144058]  [&lt;ffffffff8115b260&gt;] kmemdup+0x20/0x50
[    1.144058]  [&lt;ffffffff815147bb&gt;] efi_pstore_read_func.part.1+0x12b/0x170
[    1.144058]  [&lt;ffffffff81514800&gt;] ? efi_pstore_read_func.part.1+0x170/0x170
[    1.144058]  [&lt;ffffffff815148b4&gt;] efi_pstore_read_func+0xb4/0xe0
[    1.144058]  [&lt;ffffffff81512b7b&gt;] __efivar_entry_iter+0xfb/0x120
[    1.144058]  [&lt;ffffffff8151428f&gt;] efi_pstore_read+0x3f/0x50
[    1.144058]  [&lt;ffffffff8128d7ba&gt;] pstore_get_records+0x9a/0x150
[    1.158207]  [&lt;ffffffff812af25c&gt;] ? selinux_d_instantiate+0x1c/0x20
[    1.158207]  [&lt;ffffffff8128ce30&gt;] ? parse_options+0x80/0x80
[    1.158207]  [&lt;ffffffff8128ced5&gt;] pstore_fill_super+0xa5/0xc0
[    1.158207]  [&lt;ffffffff811ae7d2&gt;] mount_single+0xa2/0xd0
[    1.158207]  [&lt;ffffffff8128ccf8&gt;] pstore_mount+0x18/0x20
[    1.158207]  [&lt;ffffffff811ae8b9&gt;] mount_fs+0x39/0x1b0
[    1.158207]  [&lt;ffffffff81160550&gt;] ? __alloc_percpu+0x10/0x20
[    1.158207]  [&lt;ffffffff811c9493&gt;] vfs_kern_mount+0x63/0xf0
[    1.158207]  [&lt;ffffffff811cbb0e&gt;] do_mount+0x23e/0xa20
[    1.158207]  [&lt;ffffffff8115b51b&gt;] ? strndup_user+0x4b/0xf0
[    1.158207]  [&lt;ffffffff811cc373&gt;] SyS_mount+0x83/0xc0
[    1.158207]  [&lt;ffffffff81673cc2&gt;] system_call_fastpath+0x16/0x1b
[    1.158207] ---[ end trace 61981bc62de9f6f4 ]---

Signed-off-by: Seiji Aguchi &lt;seiji.aguchi@hds.com&gt;
Tested-by: Madper Xie &lt;cxie@redhat.com&gt;
Cc: stable@kernel.org
Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently, when mounting pstore file system, a read callback of
efi_pstore driver runs mutiple times as below.

- In the first read callback, scan efivar_sysfs_list from head and pass
  a kmsg buffer of a entry to an upper pstore layer.
- In the second read callback, rescan efivar_sysfs_list from the entry
  and pass another kmsg buffer to it.
- Repeat the scan and pass until the end of efivar_sysfs_list.

In this process, an entry is read across the multiple read function
calls. To avoid race between the read and erasion, the whole process
above is protected by a spinlock, holding in open() and releasing in
close().

At the same time, kmemdup() is called to pass the buffer to pstore
filesystem during it. And then, it causes a following lockdep warning.

To make the dynamic memory allocation runnable without taking spinlock,
holding off a deletion of sysfs entry if it happens while scanning it
via efi_pstore, and deleting it after the scan is completed.

To implement it, this patch introduces two flags, scanning and deleting,
to efivar_entry.

On the code basis, it seems that all the scanning and deleting logic is
not needed because __efivars-&gt;lock are not dropped when reading from the
EFI variable store.

But, the scanning and deleting logic is still needed because an
efi-pstore and a pstore filesystem works as follows.

In case an entry(A) is found, the pointer is saved to psi-&gt;data.  And
efi_pstore_read() passes the entry(A) to a pstore filesystem by
releasing  __efivars-&gt;lock.

And then, the pstore filesystem calls efi_pstore_read() again and the
same entry(A), which is saved to psi-&gt;data, is used for resuming to scan
a sysfs-list.

So, to protect the entry(A), the logic is needed.

[    1.143710] ------------[ cut here ]------------
[    1.144058] WARNING: CPU: 1 PID: 1 at kernel/lockdep.c:2740 lockdep_trace_alloc+0x104/0x110()
[    1.144058] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
[    1.144058] Modules linked in:
[    1.144058] CPU: 1 PID: 1 Comm: systemd Not tainted 3.11.0-rc5 #2
[    1.144058]  0000000000000009 ffff8800797e9ae0 ffffffff816614a5 ffff8800797e9b28
[    1.144058]  ffff8800797e9b18 ffffffff8105510d 0000000000000080 0000000000000046
[    1.144058]  00000000000000d0 00000000000003af ffffffff81ccd0c0 ffff8800797e9b78
[    1.144058] Call Trace:
[    1.144058]  [&lt;ffffffff816614a5&gt;] dump_stack+0x54/0x74
[    1.144058]  [&lt;ffffffff8105510d&gt;] warn_slowpath_common+0x7d/0xa0
[    1.144058]  [&lt;ffffffff8105517c&gt;] warn_slowpath_fmt+0x4c/0x50
[    1.144058]  [&lt;ffffffff8131290f&gt;] ? vsscanf+0x57f/0x7b0
[    1.144058]  [&lt;ffffffff810bbd74&gt;] lockdep_trace_alloc+0x104/0x110
[    1.144058]  [&lt;ffffffff81192da0&gt;] __kmalloc_track_caller+0x50/0x280
[    1.144058]  [&lt;ffffffff815147bb&gt;] ? efi_pstore_read_func.part.1+0x12b/0x170
[    1.144058]  [&lt;ffffffff8115b260&gt;] kmemdup+0x20/0x50
[    1.144058]  [&lt;ffffffff815147bb&gt;] efi_pstore_read_func.part.1+0x12b/0x170
[    1.144058]  [&lt;ffffffff81514800&gt;] ? efi_pstore_read_func.part.1+0x170/0x170
[    1.144058]  [&lt;ffffffff815148b4&gt;] efi_pstore_read_func+0xb4/0xe0
[    1.144058]  [&lt;ffffffff81512b7b&gt;] __efivar_entry_iter+0xfb/0x120
[    1.144058]  [&lt;ffffffff8151428f&gt;] efi_pstore_read+0x3f/0x50
[    1.144058]  [&lt;ffffffff8128d7ba&gt;] pstore_get_records+0x9a/0x150
[    1.158207]  [&lt;ffffffff812af25c&gt;] ? selinux_d_instantiate+0x1c/0x20
[    1.158207]  [&lt;ffffffff8128ce30&gt;] ? parse_options+0x80/0x80
[    1.158207]  [&lt;ffffffff8128ced5&gt;] pstore_fill_super+0xa5/0xc0
[    1.158207]  [&lt;ffffffff811ae7d2&gt;] mount_single+0xa2/0xd0
[    1.158207]  [&lt;ffffffff8128ccf8&gt;] pstore_mount+0x18/0x20
[    1.158207]  [&lt;ffffffff811ae8b9&gt;] mount_fs+0x39/0x1b0
[    1.158207]  [&lt;ffffffff81160550&gt;] ? __alloc_percpu+0x10/0x20
[    1.158207]  [&lt;ffffffff811c9493&gt;] vfs_kern_mount+0x63/0xf0
[    1.158207]  [&lt;ffffffff811cbb0e&gt;] do_mount+0x23e/0xa20
[    1.158207]  [&lt;ffffffff8115b51b&gt;] ? strndup_user+0x4b/0xf0
[    1.158207]  [&lt;ffffffff811cc373&gt;] SyS_mount+0x83/0xc0
[    1.158207]  [&lt;ffffffff81673cc2&gt;] system_call_fastpath+0x16/0x1b
[    1.158207] ---[ end trace 61981bc62de9f6f4 ]---

Signed-off-by: Seiji Aguchi &lt;seiji.aguchi@hds.com&gt;
Tested-by: Madper Xie &lt;cxie@redhat.com&gt;
Cc: stable@kernel.org
Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>x86/efi: Runtime services virtual mapping</title>
<updated>2013-11-02T11:09:36+00:00</updated>
<author>
<name>Borislav Petkov</name>
<email>bp@suse.de</email>
</author>
<published>2013-10-31T16:25:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d2f7cbe7b26a74dbbbf8f325b2a6fd01bc34032c'/>
<id>d2f7cbe7b26a74dbbbf8f325b2a6fd01bc34032c</id>
<content type='text'>
We map the EFI regions needed for runtime services non-contiguously,
with preserved alignment on virtual addresses starting from -4G down
for a total max space of 64G. This way, we provide for stable runtime
services addresses across kernels so that a kexec'd kernel can still use
them.

Thus, they're mapped in a separate pagetable so that we don't pollute
the kernel namespace.

Add an efi= kernel command line parameter for passing miscellaneous
options and chicken bits from the command line.

While at it, add a chicken bit called "efi=old_map" which can be used as
a fallback to the old runtime services mapping method in case there's
some b0rkage with a particular EFI implementation (haha, it is hard to
hold up the sarcasm here...).

Also, add the UEFI RT VA space to Documentation/x86/x86_64/mm.txt.

Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We map the EFI regions needed for runtime services non-contiguously,
with preserved alignment on virtual addresses starting from -4G down
for a total max space of 64G. This way, we provide for stable runtime
services addresses across kernels so that a kexec'd kernel can still use
them.

Thus, they're mapped in a separate pagetable so that we don't pollute
the kernel namespace.

Add an efi= kernel command line parameter for passing miscellaneous
options and chicken bits from the command line.

While at it, add a chicken bit called "efi=old_map" which can be used as
a fallback to the old runtime services mapping method in case there's
some b0rkage with a particular EFI implementation (haha, it is hard to
hold up the sarcasm here...).

Also, add the UEFI RT VA space to Documentation/x86/x86_64/mm.txt.

Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi: Add proper definitions for some EFI function pointers.</title>
<updated>2013-09-25T11:34:33+00:00</updated>
<author>
<name>Roy Franz</name>
<email>roy.franz@linaro.org</email>
</author>
<published>2013-09-22T22:45:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ed37ddffe201bfad7be3c45bc08bd65b5298adca'/>
<id>ed37ddffe201bfad7be3c45bc08bd65b5298adca</id>
<content type='text'>
The x86/AMD64 EFI stubs must use a call wrapper to convert between
the Linux and EFI ABIs, so void pointers are sufficient.  For ARM,
the ABIs are compatible, so we can directly invoke the function
pointers.  The functions that are used by the ARM stub are updated
to match the EFI definitions.
Also add some EFI types used by EFI functions.

Signed-off-by: Roy Franz &lt;roy.franz@linaro.org&gt;
Acked-by: Mark Salter &lt;msalter@redhat.com&gt;
Reviewed-by: Grant Likely &lt;grant.likely@linaro.org&gt;
Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The x86/AMD64 EFI stubs must use a call wrapper to convert between
the Linux and EFI ABIs, so void pointers are sufficient.  For ARM,
the ABIs are compatible, so we can directly invoke the function
pointers.  The functions that are used by the ARM stub are updated
to match the EFI definitions.
Also add some EFI types used by EFI functions.

Signed-off-by: Roy Franz &lt;roy.franz@linaro.org&gt;
Acked-by: Mark Salter &lt;msalter@redhat.com&gt;
Reviewed-by: Grant Likely &lt;grant.likely@linaro.org&gt;
Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
