On Fri, Mar 06, 2015 at 11:50:54AM -0800, Yinghai Lu wrote:
On Fri, Mar 6, 2015 at 5:33 AM, Borislav Petkov b...@suse.de wrote:
However, the setup_data linked list and thus the element which contains
kaslr_enabled is chained together using physical addresses. At the
time when we access
On Fri, Mar 06, 2015 at 11:41:57AM +, Kweh, Hock Leong wrote:
# cat /any/path/capsule.bin /sys/devices/platform/efi_capsule/capsule_load
This is straight-forward and clean.
or doing:
# echo /any/path/capsule.bin
/sys/devices/platform/efi_capsule/capsule_load
This is strange and
: f47233c2d34f (x86/mm/ASLR: Propagate base load address calculation)
Cc: Matt Fleming matt.flem...@intel.com
Cc: Borislav Petkov b...@suse.de
Cc: Kees Cook keesc...@chromium.org
Cc: Jiri Kosina jkos...@suse.cz
Acked-by: Jiri Kosina jkos...@suse.cz
Signed-off-by: Yinghai Lu ying...@kernel.org
On Wed, Mar 04, 2015 at 12:00:34AM -0800, Yinghai Lu wrote:
commit e6023367d779 (x86, kaslr: Prevent .bss from overlaping initrd)
introduced one run_size for kaslr.
We do not need to have home grown run_size.
We should use real runtime size (include copy/decompress) aka init_size
Why?
On Wed, Mar 04, 2015 at 12:00:35AM -0800, Yinghai Lu wrote:
bp found data from boot stage can not be used kernel stage.
Actually those data area is overlapped with VO kernel bss stage, and
clear_bss()
VO kernel bss stage?
I'm sure you can think of a better explanation. Right now I'm
On Thu, Mar 05, 2015 at 03:08:42PM -0800, Andy Lutomirski wrote:
No. Only root should be able to load capsules, but even root may not
be able to write to /lib.
So basically what we want to do is:
# cat /any/path/to/efi/capsule/accessible/to/root/efi_capsule.img
/sys/firmware/efi/update
Now
this code.
Fixes: f47233c2d34f (x86/mm/ASLR: Propagate base load address calculation)
Cc: Matt Fleming matt.flem...@intel.com
Cc: Borislav Petkov b...@suse.de
Cc: Kees Cook keesc...@chromium.org
Cc: Jiri Kosina jkos...@suse.cz
Acked-by: Jiri Kosina jkos...@suse.cz
Signed-off-by: Yinghai Lu
On Tue, Mar 03, 2015 at 12:37:54PM -0800, Andy Lutomirski wrote:
The user *should not* be required to have write access to anything in
/lib to install a UEFI capsule that they download from their
motherboard vendor's website. /lib belongs to the distro, and UEFI
capsules do not belong to the
On Mon, Mar 02, 2015 at 10:58:23AM -0800, Yinghai Lu wrote:
On Mon, Mar 2, 2015 at 6:53 AM, Borislav Petkov b...@suse.de wrote:
Well, it seems to work here but it still doesn't look reliable enough to
me. And this addon_zo thing of arbitrary 256K is strange.
Thanks for check that out
On Mon, Mar 02, 2015 at 03:04:30AM -0800, Yinghai Lu wrote:
We can not assume that range is safe to use.
Please check attach one that should fix the problem really.
Well, it seems to work here but it still doesn't look reliable enough to
me. And this addon_zo thing of arbitrary 256K is
On Sat, Feb 28, 2015 at 06:40:39PM -0800, Yinghai Lu wrote:
oh, no. the offending commit already got into linus tree.
We're working on it, follow this thread:
http://lkml.kernel.org/r/1424929021.10337.24.ca...@intel.com
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you
On Sun, Mar 01, 2015 at 04:23:51PM +0100, Ingo Molnar wrote:
I think that's a different bug.
parse_kaslr_setup() is simply bogus, it does:
kaslr_enabled = (bool)(pa_data + sizeof(struct setup_data));
Well, we found that while debugging the other issue too:
On Sun, Mar 01, 2015 at 11:27:48AM -0800, Yinghai Lu wrote:
other 7 should also address the problem in
http://lkml.kernel.org/r/1424929021.10337.24.ca...@intel.com
No, they don't:
[0.00] parse_setup_data: data: 0x2206e50 (va: ff200e50) { next:
0x0, type: 0x0, len: 16,
On Sun, Mar 01, 2015 at 12:24:08PM -0800, Yinghai Lu wrote:
static allocation in misc.c can not be used to kernel/head_64.S stage safely.
Correct. One possibility that works is sticking it right below
LOAD_PHYSICAL_ADDR:
+static void add_kaslr_setup_data(struct boot_params *params,
+
On Thu, Feb 26, 2015 at 07:30:54AM -0800, Andy Lutomirski wrote:
How can the error code be propagated? Would that echo command fail in
case of error?
Yeah, either that or we can put the error code in the sysfs file which
userspace can cat.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim
On Wed, Feb 25, 2015 at 12:38:20PM +, Kweh, Hock Leong wrote:
The reason we use this interface for efi capsule is that efi capsule
support multi binaries to be uploaded and each binary file name
can be different.
So you can write the file path to a second file and reload then, once
per
On Tue, Feb 24, 2015 at 12:49:09PM +, Kweh, Hock Leong wrote:
So the process steps basically look like this:
1.) cat capsule_ticket=== acquire a number and lock mutex then
expose
firmware_class user helper
On Fri, Feb 06, 2015 at 01:00:12AM -0500, Parmeshwr Prasad wrote:
I am really sorry that I could not mentioned for what purpose this patch is .
I wanted this patch to be included along with your patch. As your patch is
To add “debug” cmdline in efi=”option”.
There are some messages in
On Thu, Feb 05, 2015 at 11:18:46AM +0800, Dave Young wrote:
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 0238d612750e..14cec75d7e74 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -940,6 +940,7 @@ extern int __init efi_setup_pcdp_console(char *);
#define
On Thu, Feb 05, 2015 at 07:45:10AM -0500, Parmeshwr Prasad wrote:
It is better if we add some printk from efifb messages.
Please review the below patch.
First of all, we saw you patch.
Then,
From 7fbac896ab87f1b37646ac2f49bb8216ec330642 Mon Sep 17 00:00:00 2001
From: Parmeshwr Prasad
and late environments more apparent.
Reported-by: Andy Lutomirski l...@amacapital.net
Cc: Borislav Petkov b...@alien8.de
Signed-off-by: Matt Fleming matt.flem...@intel.com
Boots fine on my Dell box.
Tested-by: Borislav Petkov b...@suse.de
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your
From: Borislav Petkov b...@suse.de
Date: Mon, 26 Jan 2015 19:49:59 +0100
Subject: [PATCH] efi, x86: Add a debug option to the efi= cmdline
... and hide the memory regions dump behind it. Make it default-off.
Signed-off-by: Borislav Petkov b...@suse.de
Link: http://lkml.kernel.org/r
On Fri, Jan 30, 2015 at 10:06:13AM -0800, Randy Dunlap wrote:
Please update Documentation/kernel-parameters.txt also.
Good idea. Done. Thanks.
:-)
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line unsubscribe
On Wed, Jan 21, 2015 at 12:48:58AM -0500, Jon Masters wrote:
We have on a number of occasions found just this output useful in
debugging boot issues on ARM servers
We can turn it on by default on ARM and off on x86...
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
On Wed, Jan 14, 2015 at 10:38:25AM -0800, Andy Lutomirski wrote:
That's not a real MCE, though -- it happens synchronously instead of
MCE can be synchronous in a sense too, as a result of executing an insn,
for example, i.e., EIPV bit set.
at MCE priority with all the associated messiness. Or
On Wed, Jan 14, 2015 at 10:27:47AM -0800, Andy Lutomirski wrote:
How are you manually triggering an MCE? I've been playing with some
MCE stuff recently, but the only reasonably reliable way I know of to
trigger an MCE is using WHEA, and I don't have a box with WHEA, and I
assume your ASUS
On Mon, Dec 22, 2014 at 10:58:59AM +, Ard Biesheuvel wrote:
Split of the remapping code from efi_config_init() so that the caller
can perform its own remapping. This is necessary to correctly handle
virtually remapped UEFI memory regions under kexec, as efi.systab will
have been updated to
On Mon, Dec 29, 2014 at 09:25:15AM +, Ard Biesheuvel wrote:
Do you have any comments regarding patches #3 and #6 in this series?
Sorry, have had no time so far to take a look. Holidays and all...
You're on the TODO list though :-)
--
Regards/Gruss,
Boris.
--
--
To unsubscribe from this
From: Borislav Petkov b...@suse.de
Call it what it does - unparse is plain-misleading.
Signed-off-by: Borislav Petkov b...@suse.de
---
block/partitions/efi.c | 2 +-
drivers/firmware/efi/efi.c | 4 ++--
drivers/firmware/efi/efivars.c | 6 +++---
fs/efivarfs/super.c| 2
On Tue, Dec 09, 2014 at 04:35:33PM +0100, Laszlo Ersek wrote:
I disagree with the patch in general, and I strongly disagree with this
specific change in particular. This part:
- breaks the alignment for the right side of the table
Well, we can start by removing the sizes - they're useless
On Tue, Nov 25, 2014 at 02:28:04PM -0500, Peter Jones wrote:
Add sysfs files for EFI System Resource Table under
/sys/firmware/efi/esrt and for each EFI System Resource Entry under
entries/ as a subdir.
Ok, let me make sure I know what I'm looking at:
This is a table which is supposed to
On Fri, Nov 28, 2014 at 06:10:23PM +, Matt Fleming wrote:
Folks,
I'm taking annual leave for all of December, so I've asked Ricardo and
Borislav (Cc'd) to pick up and review any patches that hit the mailing
list and send pull requests to the tip tree.
This is just a heads up so no one
On Tue, Nov 25, 2014 at 05:39:25PM +, Matt Fleming wrote:
On Tue, 18 Nov, at 01:57:02PM, Ard Biesheuvel wrote:
Improve the handling of /dev/mem mappings under CONFIG_STRICT_DEVMEM by:
- allowing read-only access to parts of System RAM that are not
considered memory by the kernel, this
On Tue, Nov 11, 2014 at 11:38:31AM +, One Thousand Gnomes wrote:
I don't believe there is anything which prevents the CSM from faking a
CMOS clock using SMM from whatever is actually in the hardware.
HPET in SMM? Oh, sure, definitely.
--
Regards/Gruss,
Boris.
Sent from a fat crate
On Sun, Nov 09, 2014 at 06:37:46PM +0100, Pali Rohár wrote:
this patch totally disabled efi rfc driver on x86 machines at
compile time. But on some x86 machines it working without crash
and reading from file /sys/class/rtc/rtc*/since_epoch returns
correct information. So why to disable
On Tue, Oct 07, 2014 at 03:42:31PM +0100, Matt Fleming wrote:
From: Matt Fleming matt.flem...@intel.com
The EFI capsule mechanism allows data blobs to be passed to the EFI
firmware. This patch just introduces the main infrastruture for
interacting with the firmware.
Once a capsule has
On Sat, Sep 13, 2014 at 11:36:16AM -0700, Ricardo Neri wrote:
Being more verbose about this kind of illegal access from the firmware
increases the likelihood of this kind firmware bugs to be fixed.
I sincerely hope you're right and, more importantly, how do we make sure
those warnings get seen
On Tue, Jul 29, 2014 at 01:09:21PM -0400, Prarit Bhargava wrote:
The current debug print in EFI does
[0.00] efi: mem84: type=3, attr=0xf,
range=[0x645b5000-0x645fb000) (0MB)
and rounds off the size to 0MB and isn't very useful. We should print this in
Kib. After
On Tue, Jul 29, 2014 at 03:42:55PM -0700, David Rientjes wrote:
If Prarit is going to implement this suggested reverse memparse() ...
The only meaningful argument about the formatting here IMO is what
people staring at this output are going to understand from it.
And since those people most
Addomg linux-efi to CC for the efi bits. Please CC it on your next
submission.
Thanks.
On Tue, Jun 03, 2014 at 09:07:02AM -0400, Vivek Goyal wrote:
This patch does two thigns. It passes EFI run time mappings to second
kernel in bootparams efi_info. Second kernel parse this info and create
new
Btw,
while we're at it, I see uv_bios_call is sometimes done with preemption
disabled around it and sometimes it is not (at least I don't see it)...
In any case, if SGI uses the EFI pagetable now too, you probably would
want to do the efi calls like the rest of x86 does them - see the 64-bit
On Fri, May 30, 2014 at 10:24:38AM +0800, Dave Young wrote:
How does /sys/firmware/efi/runtime-map/* look like with old mapping?
Can't
we look at it and figure out if it is 1:1 or not.
There's phys_addr and virt_addr, (virt_addr - phys_addr) will always be
-64G for 1:1 map,
boot failure.
To address this issue do not export runtime maps in case efi old_map so
userspace can use no efi boot instead.
Signed-off-by: Dave Young dyo...@redhat.com
Acked-by: Borislav Petkov b...@suse.de
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting
On Thu, May 29, 2014 at 08:45:20AM -0400, Vivek Goyal wrote:
I am curious that what's the meaning of 1:1 mapping here? So far I
thought that means virt and physical addresses are same but that does
not seem to be the case. So what does it mean?
1:1 mapping in the EFI's case (and maybe in any
On Mon, May 19, 2014 at 03:47:31PM -0700, H. Peter Anvin wrote:
efi_call can happen in an irq context (pstore) and there we really need
to make sure we're not scribbling over FPU state while we've interrupted
a thread or kernel mode with a live FPU state. Therefore, use the
On Sat, May 17, 2014 at 05:25:47PM +0200, Francis Moreau wrote:
[ +0.018677] general protection fault: [#1] PREEMPT SMP
[ +0.68] Modules linked in: usb_storage tun raid1 md_mod loop fuse
joydev coretemp hwmon arc4 intel_rapl x86_pkg_temp_thermal
intel_powerclamp kvm_intel
. where a 64-bit kernel is
booted with 32-bit EFI firmware.
Delete the dead code.
Signed-off-by: Matt Fleming matt.flem...@intel.com
Acked-by: Borislav Petkov b...@suse.de
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from
On Wed, Feb 05, 2014 at 03:45:36PM -0600, Alex Thorlton wrote:
While working on an answer to this question, I ran across another issue
on some newer hardware, that looks like it's definitely related to this
problem, and might be the root cause.
When booting on a UV2 we die in
On Fri, Jan 31, 2014 at 08:02:21AM -0600, Russ Anderson wrote:
I'm not sure what you are asking for. We had a reliable
way to boot before the recent patch broke it. (commit
d2f7cbe7b26a74dbbbf8f325b2a6fd01bc34032c)
So we should stop any further development just because your machines did
boot
On Fri, Jan 31, 2014 at 03:23:18PM +0100, Borislav Petkov wrote:
So we should stop any further development just because your machines did
boot nicely before that. What about the other machines and kexec we're
fixing with the work above? Jeez...
Alternatively, we can force the old memmap method
On Wed, Jan 29, 2014 at 04:23:47PM +, Matt Fleming wrote:
From: Matt Fleming matt.flem...@intel.com
handover_offset is now filled out by build.c. Don't set a default value
as it will be overwritten anyway.
Signed-off-by: Matt Fleming matt.flem...@intel.com
Acked-by: Borislav Petkov b
On Mon, Jan 20, 2014 at 01:38:02PM +, Matt Fleming wrote:
+config EFI_PGT_DUMP
+ bool Dump the EFI pagetable
+ depends on EFI X86_PTDUMP
+ ---help---
+ Enable this if you want to dump the EFI page table before
+ enabling virtual mode. This can be used to debug
From: Borislav Petkov b...@suse.de
This is very useful for debugging issues with the recently added
pagetable switching code for EFI virtual mode.
Signed-off-by: Borislav Petkov b...@suse.de
Tested-by: Toshi Kani toshi.k...@hp.com
---
arch/x86/Kconfig | 9 +
arch/x86
From: Borislav Petkov b...@suse.de
Currently, running SetVirtualAddressMap() and passing the physical
address of the virtual map array was working only by a lucky coincidence
because the memory was present in the EFI page table too. Until Toshi
went and booted this on a big HP box - the krealloc
On Mon, Jan 13, 2014 at 01:32:40PM +0800, Dave Young wrote:
pr_info? This is for debug purpose, maybe pr_debug is better?
I hate pr_debug as it depends on other defines I have to have defined
properly in order just so I get output.
How about do not limit to only if (pgd) case, instead do
On Mon, Jan 13, 2014 at 01:40:39PM +0800, Dave Young wrote:
Adding a safeguard check for desc_size is better though currently it's
impossible for the desc_size PAGE_SIZE?
Huh, what?
sizeof(efi_memory_desc_t) is only 40 bytes AFAICT.
--
Regards/Gruss,
Boris.
Sent from a fat crate under
On Mon, Jan 13, 2014 at 06:48:10AM -0800, Arjan van de Ven wrote:
MODULE_LICENSE(GPL);
MODULE_AUTHOR(Arjan van de Ven ar...@linux.intel.com);
MODULE_DESCRIPTION(Kernel debugging helper that dumps pagetables);
personally I consider it good form to always have this kind of
information in .c
@@ asmlinkage void __init start_kernel(void
check_bugs();
- acpi_early_init(); /* before LAPIC and SMP init */
sfi_init_late();
if (efi_enabled(EFI_RUNTIME_SERVICES)) {
Looks good both on kvm+OVMF and on my Dell EFI box.
Tested-by: Borislav Petkov b...@suse.de
Toshi has
From: Borislav Petkov b...@suse.de
Ok, here's v2 rebased and rediffed against tip (which has the relevant
efi branches).
Toshi, I'm pushing it to:
git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git#efi-fixes
so that you can give it another run and so that the build robot can poke
From: Borislav Petkov b...@suse.de
Currently, running SetVirtualAddressMap() and passing the physical
address of the virtual map array was working only by a lucky coincidence
because the memory was present in the EFI page table too. Until Toshi
went and booted this on a big HP box - the krealloc
From: Borislav Petkov b...@suse.de
With reusing the -trampoline_pgd page table for mapping EFI regions in
order to use them after having switched to EFI virtual mode, it is very
useful to be able to dump aforementioned page table in dmesg. This adds
that functionality through the walk_pgd_level
From: Borislav Petkov b...@suse.de
This is very useful for debugging issues with the recently added
pagetable switching code for EFI virtual mode.
Signed-off-by: Borislav Petkov b...@suse.de
---
arch/x86/platform/efi/efi.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch
On Thu, Dec 19, 2013 at 08:30:48PM -0800, H. Peter Anvin wrote:
On 12/19/2013 08:24 PM, joeyli wrote:
I agreed, but userspace application should not be too often to access
RTC. Maybe only when system boot and set timezone.
This is, quite frankly, an idiotic argument.
TBH, I've been
On Wed, Dec 18, 2013 at 05:07:57PM +0800, Dave Young wrote:
How about firstly count the md numbers in the 1st loop, then
get/roundup the total size, alloc the pages, map the mds one by one in
another loop.
No need as most systems would never need to reallocate. Even on Toshi's
big system, the
On Tue, Dec 17, 2013 at 12:10:24PM +, Matt Fleming wrote:
You sunk my i386 battleship,
/home/build/git/efi/arch/x86/platform/efi/efi.c:824:24: error: ‘struct
real_mode_header’ has no member named ‘trampoline_pgd’
make[4]: *** [arch/x86/platform/efi/efi.o] Error 1
make[3]: ***
On Tue, Dec 17, 2013 at 02:34:36PM +0800, Dave Young wrote:
They are moved to efi.c efi_setup_init(), I'm not sure if I expained
clear enough, in current code parse_efi_setup only accept one argument
phys_addr so I will mapping it with sizeof(struct setup_data) to
get the payload size then get
On Mon, Dec 16, 2013 at 10:00:10AM +0800, Dave Young wrote:
- print_efi_memmap();
+ if (efi_setup) {
+ int s;
+ struct efi_setup_data *data;
+
+ s = sizeof(*data) + nr_efi_runtime_map * sizeof(data-map[0]);
+ data = early_memremap(efi_setup, s);
From: Borislav Petkov b...@suse.de
Hi guys,
this is the result of Toshi and me debugging a #GP on one of his big HP
boxes sporting UEFI. Each commit message should be self-explanatory so
please look there.
This has more or less an RFC nature thus I'm sending it now to collect
feedback
From: Borislav Petkov b...@suse.de
This is very useful for debugging issues with the recently added
pagetable switching code for EFI virtual mode.
Signed-off-by: Borislav Petkov b...@suse.de
---
arch/x86/platform/efi/efi.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch
From: Borislav Petkov b...@suse.de
Currently, running SetVirtualAddressMap() and passing the physical
address of the virtual map array was working only by a lucky coincidence
because the memory was present in the EFI page table too. Until Toshi
went and booted this on a big HP box - the krealloc
From: Borislav Petkov b...@suse.de
With reusing the -trampoline_pgd page table for mapping EFI regions in
order to use them after having switched to EFI virtual mode, it is very
useful to be able to dump aforementioned page table in dmesg. This adds
that functionality through the walk_pgd_level
On Mon, Dec 09, 2013 at 05:42:23PM +0800, Dave Young wrote:
For kexec/kdump kernel efi runtime mappings are saved, printing original whole
memmap ranges does not make sense anymore. So introduce a new function to only
print runtime maps in case kexec/kdump kernel is used.
changelog:
Matt:
/* boot protocal version (in hex, 0x prefixed)*/
Changelog:
Greg: use __ATTR_RO() and group attr.
Matt and Boris: Documentation improvement, code indentation.
Signed-off-by: Dave Young dyo...@redhat.com
Acked-by: Borislav Petkov b...@suse.de
--
Regards/Gruss,
Boris.
Sent from
as reserved ranges and later
ioremap will be fine with it.
changes:
Boris: improve patch description
Signed-off-by: Dave Young dyo...@redhat.com
Acked-by: Borislav Petkov b...@suse.de
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe
On Thu, Dec 12, 2013 at 03:13:37PM +0800, Dave Young wrote:
BTW, I will restructure the whole code when I move them to
efi_kexec.c, so no worry about it? If you have strong opinion I can
move them though.
Well, if it were me, I'd do it now so that it'll see more testing.
Later, it will be only
On Thu, Dec 12, 2013 at 10:36:17AM +0800, Dave Young wrote:
Sorry that I forgot to explain this in changelog, should ask you before.
I did try moving it to efisubsys_init but it need add extern declaration
So what? Add it.
for efi_runtime_map_init. Since link order will ensure it being
On Thu, Dec 12, 2013 at 03:17:43PM +0800, Dave Young wrote:
Rethink about this issue, moving them to efi_$(BITS).c I need move the
efi_setup from a static variable to an extern, It looks not worth.
Dave, would you please do what is suggested to you? A big part of
the efi code is split into
On Tue, Dec 10, 2013 at 03:25:49PM -0800, Andrew Morton wrote:
On Mon, 9 Dec 2013 17:42:13 +0800 Dave Young dyo...@redhat.com wrote:
Here is the V5 patchset for supporting kexec kernel efi runtime.
It's unclear (to me) who's supposed to merge this lot. It's a kexec
patch which actually
On Mon, Dec 09, 2013 at 05:42:14PM +0800, Dave Young wrote:
There's a lot of sparse warnings for code like below:
void *a = early_memremap(phys_addr, size);
early_memremap intend to map kernel memory with ioremap facility, the return
pointer should be a kernel ram pointer instead of iomem
On Thu, Dec 05, 2013 at 08:56:02AM -0700, Toshi Kani wrote:
The smbios in efi_setup_data is necessary for kexec to pass the physical
address of the SMBIOS table from the 1st kernel to the 2nd kernel.
The kernel boot sequence proceeds in the following order. Step 2
requires efi.smbios to be
On Mon, Dec 02, 2013 at 10:59:42AM +0800, Dave Young wrote:
They are only called if there's setup_data SETUP_EFI passed in. Yes, I
think only kexec need that part of code. But I hesitated to mess the
code with a lot of #if. Will think about it.
Well, the accepted strategy with the efi code is
On Fri, Nov 29, 2013 at 05:40:35PM +0800, Dave Young wrote:
Matt are suggesting to below one, is it ok to you? I'm fine with both.
The efi runtime services can only be switched to virtual mode once
without rebooting. The kexec kernel must maintain the same physical
to virtual address mappings
On Fri, Nov 29, 2013 at 05:14:16PM +0800, Dave Young wrote:
That's reserved for future extension use, who knows if we will need to
pass other fields in the future.
Hrrmmm, 8*64 = 64 Bytes?? And you can't change it later because of the
situation where machines might be using older kexec-tools?
On Fri, Nov 29, 2013 at 04:50:50PM +0800, Dave Young wrote:
It's for debugging purpose, I think it's helpful.
Why? The first kernel did dump it already.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line
On Tue, Nov 26, 2013 at 01:57:51PM +0800, Dave Young wrote:
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 directly
On Wed, Nov 27, 2013 at 05:29:46PM +0800, Dave Young wrote:
I would like to send a new version which addressing several issues for
code structure improvement and changelog etc.
If there's no further comments I will send them tommorrow.
As a rule of thumb you should wait ~week and give chance
the flag and switch to old logic.
changelog:
Matt: + defined(CONFIG_KEXEC)
HPA: document the flag.
Signed-off-by: Dave Young dyo...@redhat.com
Other than that:
Acked-by: Borislav Petkov b...@suse.de
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine
On Tue, Nov 26, 2013 at 01:57:55PM +0800, Dave Young wrote:
kexec-tools use boot_params for getting the 1st kernel hardware_subarch,
the kexec kernel efi runtime support also need read the old efi_info from
boot_params. Currently it exists in debugfs which is not a good place for
such
On Tue, Nov 26, 2013 at 01:57:50PM +0800, Dave Young wrote:
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 2e2fbde..5d85956 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -32,6 +32,9 @@ struct efi __read_mostly efi = {
.hcdp
On Mon, Nov 25, 2013 at 05:19:57PM +0800, Dave Young wrote:
Sigh, looks like I should move to git-send-email for less error prone.
You won't regret it :-)
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line
On Fri, Nov 22, 2013 at 10:48:50AM +0800, Dave Young wrote:
efi.config_table = (unsigned long)efi.systab-tables;
efi.fw_vendor= (unsigned long)efi.systab-fw_vendor;
efi.runtime = (unsigned long)efi.systab-runtime;
Hmm, UEFI spec mentions the them like below so I use
On Thu, Nov 21, 2013 at 02:17:09PM +0800, dyo...@redhat.com wrote:
--- efi.orig/arch/x86/platform/efi/efi.c
+++ efi/arch/x86/platform/efi/efi.c
@@ -653,6 +653,10 @@ void __init efi_init(void)
set_bit(EFI_SYSTEM_TABLES, x86_efi_facility);
+ efi.fw_vendor = (unsigned
On Thu, Nov 21, 2013 at 02:01:26PM -0700, Jerry Hoemann wrote:
Some platform have firmware that violate the UEFI spec and access boot service
code or data segments after the system has called ExitBootServices().
The call to efi_reserve_boot_services is a workaround to avoid using
boot service
On Thu, Nov 21, 2013 at 02:17:05PM +0800, dyo...@redhat.com wrote:
variables size and end is useless in this function, thus remove them.
Reported-by: Toshi Kani toshi.k...@hp.com
Signed-off-by: Dave Young dyo...@redhat.com
Good catch.
Acked-by: Borislav Petkov b...@suse.de
--
Regards
Matt: check return value of krealloc.
Signed-off-by: Dave Young dyo...@redhat.com
Same short comment nitpick as earlier :)
Otherwise:
Acked-by: Borislav Petkov b...@suse.de
---
arch/x86/platform/efi/efi.c | 109
++--
1 file changed, 66 insertions
: coding style
reuse __map_region
Signed-off-by: Dave Young dyo...@redhat.com
Except minor nitpick below:
Acked-by: Borislav Petkov b...@suse.de
---
arch/x86/include/asm/efi.h |1 +
arch/x86/platform/efi/efi_32.c |2 ++
arch/x86/platform/efi/efi_64.c | 10 ++
3
On Tue, Nov 05, 2013 at 04:20:07PM +0800, dyo...@redhat.com wrote:
Please help to review the patches.
Sure, but will have to wait 'til next week when I get back.
Thanks.
--
Regards/Gruss,
Boris.
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to
On Fri, Nov 01, 2013 at 09:18:25AM +0800, Dave Young wrote:
Great, thank you. BTW, I have managed to test original patch set on a
Macboot Air of my friend with usb boot, it works ok.
Ok, that's actually a very good news - the apples tend to be special wrt
uefi implementation.
--
From: Borislav Petkov b...@suse.de
This allocates, if necessary, and populates the corresponding PGD entry
with a PUD page. The next population level is a dummy macro which will
be removed by the next patch and it is added here to keep the patch
small and easily reviewable but not break bisection
From: Borislav Petkov b...@suse.de
Handle PMD-level mappings the same as PUD ones.
Signed-off-by: Borislav Petkov b...@suse.de
---
arch/x86/mm/pageattr.c | 82 +-
1 file changed, 81 insertions(+), 1 deletion(-)
diff --git a/arch/x86/mm/pageattr.c
301 - 400 of 493 matches
Mail list logo
