On Wed, Sep 16, 2015 at 01:25:06PM +0200, Ard Biesheuvel wrote:
> ... so even if we wanted to, it would be intractible to find each
> cross-section relative reference and do the fixup.
Hmm, maybe we should go and patch EFI code segments and fixup all
relative references after mapping. I mean, if y
On Wed, Sep 09, 2015 at 12:21:23PM +0100, Matt Fleming wrote:
> On Wed, 09 Sep, at 08:33:07AM, joeyli wrote:
> >
> > Yes, the machine on my hand has EFI_PROPERTIES_TABLE enabled, and it doesn't
> > boot without your patch.
>
> Awesome. Could you test the following patch instead?
>
> ---
>
> Fro
On Tue, Sep 08, 2015 at 02:29:21PM -0700, Jonathan (Zhixiong) Zhang wrote:
> /*
> + * Raw Events Report
> + *
> + * This event is generated when hardware detected a hardware
> + * error event, which may be of non-standard section as defined
> + * in UEFI spec appendix "Common Platform Error Record
On Tue, Sep 08, 2015 at 02:29:20PM -0700, Jonathan (Zhixiong) Zhang wrote:
> From: "Jonathan (Zhixiong) Zhang"
>
> UEFI spec allows for non-standard section in Common Platform Error
> Record. This is defined in section N.2.3 of UEFI version 2.5.
>
> Currently if the CPER section's type (UUID) do
On Mon, Aug 03, 2015 at 05:23:54PM +0100, Matt Fleming wrote:
> Rafael, Boris?
The ghes.c change looks fine I guess. The whole patchset makes sense
now, with the arch bits extracted. So
Acked-by: Borislav Petkov
However, we probably should work towards adhering to EFI memory
attributes on
On Thu, Jul 30, 2015 at 12:53:42AM -0700, H. Peter Anvin wrote:
> This changelog is at least partially incomprehensive. It also seems
> more than a bit aggressive to expect that 1 GB will be sufficient
> forever.
Right, before we do anything, I'd like for us to figure out first why
this is a probl
On Wed, Jul 22, 2015 at 07:06:10PM +0400, Dmitry Skorodumov wrote:
> The efi_info structure stores low 32 bits of memory map
> in efi_memmap and high 32 bits in efi_memmap_hi.
>
> While constructing pointer in the setup_e820(), need
> to take into account all 64 bit of the pointer.
>
> It is beca
On Tue, Jul 21, 2015 at 04:36:47PM -0700, Jonathan (Zhixiong) Zhang wrote:
> From: "Jonathan (Zhixiong) Zhang"
>
> Trace event is generated when hardware detected a hardware error
> event, which is of non-standard section as defined in UEFI
> spec appendix "Common Platform Error Record" (section
On Tue, Jul 21, 2015 at 04:36:46PM -0700, Jonathan (Zhixiong) Zhang wrote:
> From: "Jonathan (Zhixiong) Zhang"
>
> UEFI spec allows for non-standard section in Common Platform Error
> Record. This is defined in section N.2.3 of UEFI version 2.5.
>
> If Section Type field of Generic Error Data En
On Mon, Jun 29, 2015 at 03:49:40PM +0100, Matt Fleming wrote:
> It still makes sense to have the error message because the kernel
> literally does not know what the firmware is trying to achieve by
> setting those bits.
>
> But I agree with Josh that for the specific case of "reserved bits",
> FW_
On Mon, Jun 29, 2015 at 07:00:22AM -0700, Josh Triplett wrote:
> Definitely not FW_BUG. The field is reserved *now*; it would be
> legitimate for a new version of the BGRT spec to define one of those
> bits for something else.
Which would mean that booting old kernels on new FW which defines thos
On Mon, Jun 29, 2015 at 01:06:42PM +0100, Matt Fleming wrote:
> From: Matt Fleming
>
> It's totally legitimate, per the ACPI spec, for the firmware to set the
> BGRT 'status' field to zero to indicate that the BGRT image isn't being
> displayed, and we shouldn't be printing an error message in th
On Thu, Jun 11, 2015 at 02:14:39PM +0100, Matt Fleming wrote:
> Yeah, fair enough. Though it's worth noting that because we're calling
> firmware functions, which use the Microsoft ABI, %rbp will be saved by
> the callee function if used.
Yeah, just looked at the spec.
But you know how we don't t
On Wed, Apr 15, 2015 at 11:14:55AM +0100, Matt Fleming wrote:
> Well, I haven't come across a scenario where you need a brand new
> interface for getting it *out* of the kernel again.
Well, how are we going to read crash data on next boot then? EFI var or
what? Are we going to have a generic inter
On Tue, Apr 14, 2015 at 11:56:26AM -0400, Andy Lutomirski wrote:
> This is why I think that the right approach would be to avoid using
> firmware_class entirely for this. IMO a simple_char device would be
> the way to go (hint hint...) but other simple approaches are certainly
> possible.
Btw, di
On Sat, Mar 14, 2015 at 10:59:23AM +0100, Borislav Petkov wrote:
> In addition to what you've said, I have only one proposal: we revert
> the whole crap and do it again, this time nice and clean in tip. It'll
> stay there as long as it has to. No half-arsed commit messages, no
&
On Sat, Mar 14, 2015 at 08:53:57AM +0100, Ingo Molnar wrote:
> You are still talking only about the low level code and about low
> level symptoms, while in contrast to that the primary question with...
Thanks for doing that!
I really doubt it'll bring anything this time either but I don't care
On Tue, Mar 10, 2015 at 08:42:40AM -0700, Yinghai Lu wrote:
> In arch/x86/boot/header.S, we already use VO and ZO.
> So please keep on using them, and don't introduce "kernel proper" etc.
So you're suggesting commit messages should use variable names and
prefixes from the code instead of being hum
On Tue, Mar 10, 2015 at 08:17:01AM -0700, Yinghai Lu wrote:
> Make it not confusing.
>
> ZO: arch/x86/boot/compressed/vmlinux
> VO: vmlinux
>
> setup + ZO ==> bzImage.
>
> compressed kernel is just compressed VO.
So the two end up being the "compressed kernel" and "kernel proper".
And then the
On Tue, Mar 10, 2015 at 08:11:03AM -0700, Yinghai Lu wrote:
> Also stop using "compressed kernel" please, that is confusing.
Why?
> Just use
>
> ZO: arch/x86/boot/compressed/vmlinux
> VO: vmlinux
and this is not confusing?
Yeah, right.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your ma
On Tue, Mar 10, 2015 at 08:05:52AM -0700, Yinghai Lu wrote:
> We need to keep VO and ZO here...
Why?
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.k
On Tue, Mar 10, 2015 at 10:34:31AM +0100, Jiri Kosina wrote:
> Thanks a lot for fixing my oversight.
Bah, it was my suggestion to use setup_data in the first place, sorry
about that.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list:
Final patch:
---
From: Yinghai Lu
Date: Sat, 7 Mar 2015 14:07:17 -0800
Subject: [PATCH] x86/setup: Don't overlap vmlinux's brk with compressed
kernel's data
We already do move the compressed kernel close to the end of the buffer.
However, there's still overlapping beween kernel proper's .brk/.b
Final patch:
---
From: Yinghai Lu
Date: Sat, 7 Mar 2015 14:07:16 -0800
Subject: [PATCH] x86/setup: Move compressed kernel to the end of the buffer
Boris found that passing KASLR status through setup_data from the boot
stage cannot be used later in the kernel stage, see commit
f47233c2d34f ("x
On Mon, Mar 09, 2015 at 05:54:01PM -0700, Kees Cook wrote:
> On Sat, Mar 7, 2015 at 2:07 PM, Yinghai Lu wrote:
> > Boris found data from boot stage can not be used kernel stage.
>
> "... be used during kernel stage."
>
> Also, can you give a specific example of this problem? (Which data, used ho
+ pjones.
So reportedly, there is already a capsule-loading thing which doesn't
need the kernel at all:
https://github.com/rhinstaller/fwupdate
So why are we even wasting energy with this discussion here?
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsu
On Mon, Mar 09, 2015 at 01:06:00PM -0700, Yinghai Lu wrote:
> Yes. Just to emphasize that " We need to make sure [z_extra_offset,
> init_size) will fit ZO"
So you want to say:
"We need to make sure the compressed kernel fits in the interval
[z_extra_offset, z_extra_offset + init_size)"
?
--
R
On Mon, Mar 09, 2015 at 12:35:25PM -0700, Yinghai Lu wrote:
> Can you put back:
> "
> So need to make sure [z_extra_offset, init_size) will fit ZO, that means
> init_size need to be adjusted according to ZO size.
> That make init_size is always >= run_size.
Why?
We don't adjust init_size. We assi
On Mon, Mar 09, 2015 at 04:58:13PM +0100, Ingo Molnar wrote:
> So this would be fine as-is for v4.1, but I think we want to attempt
> to fix this in x86/urgent so that we don't have to revert the kaslr
> changes in v4.0, so it would be awesome if you could split it into two
> parts: the fix, plu
On Sat, Mar 07, 2015 at 02:07:15PM -0800, Yinghai Lu wrote:
...
I ended up committing this. Anything I've missed?
---
From: Yinghai Lu
Date: Sat, 7 Mar 2015 14:07:15 -0800
Subject: [PATCH] x86/setup: Use init_size instead of run_size
Commit
e6023367d779 ("x86, kaslr: Prevent .bss from overl
On Fri, Mar 06, 2015 at 11:53:22AM -0800, Yinghai Lu wrote:
> That will get wrong value back for kaslr_enabled in kernel stage.
> 1. When kaslr is not enabled at boot/choose_kernel_location, if kaslr_enabled
> get set wrongly in setup.c, late in module.c::get_module_load_offset
> will return not wa
On Fri, Mar 06, 2015 at 11:50:54AM -0800, Yinghai Lu wrote:
> On Fri, Mar 6, 2015 at 5:33 AM, Borislav Petkov wrote:
>
> >
> > "However, the setup_data linked list and thus the element which contains
> > kaslr_enabled is chained together using physical addresses. A
On Fri, Mar 06, 2015 at 09:49:25AM -0800, Yinghai Lu wrote:
> That is "copy and paste" instead of attachment for easy review.
> but gmail web client convert tab to spaces.
Next time you send a patch *only* for review *and* *not* for
application, do state that at the top like everyone else. Better
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 an
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 t
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
explain it that way?
> -v3: add checking return from early_memmap according to bp.
I guess with "bp" you mean me? You can call me Boris.
> Fixes: f47233c2d34f ("x86/mm/ASLR: Propagate base load address calculation")
> Cc: Matt Fleming
> Cc: Borislav Petkov
>
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
N
dable even for people who don't know
this code.
>
> Fixes: f47233c2d34f ("x86/mm/ASLR: Propagate base load address calculation")
> Cc: Matt Fleming
> Cc: Borislav Petkov
> Cc: Kees Cook
> Cc: Jiri Kosina
> Acked-by: Jiri Kosina
> Signed-off-by: Yinghai
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 t
On Mon, Mar 02, 2015 at 10:58:23AM -0800, Yinghai Lu wrote:
> On Mon, Mar 2, 2015 at 6:53 AM, Borislav Petkov 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
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 stra
On Sun, Mar 01, 2015 at 12:41:10PM -0800, Yinghai Lu wrote:
> Does not look safe yet...
Why?
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.or
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 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, data
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:
https://lkml.kernel.
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 repl
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 yo
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 f
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=””.
>
> There are some messages in efifb
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
>
From: Borislav Petkov
Subject: [PATCH v2] 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
Link: http://lkml.kernel.org/r/20141209095843.ga3...@pd.tnic
Acked-by: Laszlo Ersek
Acke
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 *);
>
has been invoked.
>
> A liberal sprinkling of comments in the thunking code should make the
> differences in early and late environments more apparent.
>
> Reported-by: Andy Lutomirski
> Cc: Borislav Petkov
> Signed-off-by: Matt Fleming
Boots fine on my Dell box.
Tested-by
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 linux-
From: Borislav Petkov
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
Link: http://lkml.kernel.org/r/20141209095843.ga3.
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. O
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
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
d by the platform, use it to round
> up all memory allocations made.
>
> Acked-by: Matt Fleming
> Signed-off-by: Ard Biesheuvel
Acked-by: Borislav Petkov
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: sen
On Thu, Dec 11, 2014 at 03:22: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.
>
> v2 with suggestions from bpetkov.
> v3 with me remembering checkpatch.
> v4 without m
From: Borislav Petkov
Call it what it does - "unparse" is plain-misleading.
Signed-off-by: Borislav Petkov
---
block/partitions/efi.c | 2 +-
drivers/firmware/efi/efi.c | 4 ++--
drivers/firmware/efi/efivars.c | 6 +++---
fs/efivarfs/super.c| 2 +-
include/l
On Wed, Dec 10, 2014 at 10:17:41AM +0800, Dave Young wrote:
> I have same feeling with you, it is too long for most of people.
>
> Since the printk code are for EFI_DEBUG, they are around the #ifdef
> so I would like to see a kernel param like efi_debug=on, so only
> efi_debug is specified then the
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, Dec 09, 2014 at 01:42:44PM +0100, Ard Biesheuvel wrote:
> The |] thing is easily fixed, though.
>
> [...]
> > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> > index 8590099ac148..6734072980ee 100644
> > --- a/drivers/firmware/efi/efi.c
> > +++ b/drivers/firmware/efi
Hi guys,
so this decoded EFI regions output is nice but can we shorten it? It
sticks too far out in the terminal more than anything else in dmesg and
staring at it needs me to resize window and such. It probably is an even
bigger problem if one's monitor hasn't switched to higher res early
during
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 de
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
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
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 u
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 c
On Tue, Oct 07, 2014 at 03:42:31PM +0100, Matt Fleming wrote:
> From: Matt Fleming
>
> 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 been passed to the
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 Wed, Jul 30, 2014 at 10:21:26AM -0700, H. Peter Anvin wrote:
> Arguably the exactness is available in the range...
... and the size too. FWIW, other region dumps don't even print size:
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x
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 oft
On Tue, Jul 29, 2014 at 06:32:56PM -0400, Prarit Bhargava wrote:
> and it was best to keep the code simple with a KiB.
You're missing the point - the output doesn't get simple with KiB. Read
the example I just gave you!
(13893632kiB) is actively *not* helping when one looks at it!
--
Regards/Gr
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.
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
> n
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
vers
On Mon, Jun 09, 2014 at 03:00:17PM -0500, Alex Thorlton wrote:
> Hi guys,
>
> We recently ran into/corrected a bug in our BIOS that was exposed by the
> recent updates to the way that the EFI code maps in memory during boot.
> Discussion here:
>
> http://comments.gmane.org/gmane.linux.kernel/1638
s will cause
> kexec 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
Acked-by: Borislav Petkov
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk
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
> >
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 05:17:01PM -0700, H. Peter Anvin wrote:
> I thought the whole point of allowing pstore in IRQ context was to
> write oopsen (panics?)
Right, so Tony meant last time we were talking about it that nvram is
too slow for collecting the whole dmesg into it (could mess up timing
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 nls_iso
On Thu, Apr 10, 2014 at 06:34:34PM +, Luck, Tony wrote:
> Speed is also a factor ... waiting for flash to update for each
> printk() would mess up timing so much that you might not see the
> problem you are chasing.
Gaah, there's that too. I guess nvram access speeds slower than in the
msec ra
Hey Tony,
so I was wondering whether we could finally put that UEFI thing to use
and log dmesg into it but then Matt pointed me to df36ac1bc2a16.
Even though those nvram devices are fragile and can only stomach a
limited amount of writes, wouldn't it be a nifty feature to have a
kernel cmdline pa
From: Borislav Petkov
Getting this thing to work with the new mapping scheme would need more
work.
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/efi.h | 1 +
arch/x86/kernel/setup.c | 10 ++
arch/x86/platform/efi/efi.c | 20
3 files changed, 23
From: Borislav Petkov
We do not enable the new efi memmap on 32-bit and thus we need to run
runtime_code_page_mkexec() unconditionally there. Fix that.
Reported-and-tested-by: Lejun Zhu
Cc: # v3.14+
Signed-off-by: Borislav Petkov
---
arch/x86/include/asm/efi.h | 2 ++
arch/x86/platform
On Tue, Feb 11, 2014 at 04:19:03PM -0600, Alex Thorlton wrote:
> Have there been any developments on this since last week, Boris? Just
> trying to make sure that we stay in the loop on this issue.
>
> Let me know if there's anything else we can do from our end to help
> expedite the process. I'm al
it 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.
>
> Signed-off-by: Matt Fleming
Acked-by: Borislav Petkov
--
Regards/Gruss,
Boris.
Sent from a fat crate und
where a 64-bit kernel is
> booted with 32-bit EFI firmware.
>
> Delete the dead code.
>
> Signed-off-by: Matt Fleming
Acked-by: Borislav Petkov
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the l
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 efi_enter_v
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
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
ble underscore prefix, which is usually reserved for
> static functions.
>
> Cc: Borislav Petkov
> Signed-off-by: Matt Fleming
Good, like the show_fault_oops() improvement.
Acked-by: Borislav Petkov
Btw, the commit title
"x86/mm/pageattr: Make __lookup_address_in_pgd() global&q
301 - 400 of 619 matches
Mail list logo
