On 08/01/13 18:49, Borislav Petkov wrote:
On Wed, Jul 31, 2013 at 10:55:27PM +0100, David Woodhouse wrote:
On Wed, 2013-07-31 at 22:54 +0200, Borislav Petkov wrote:
so I'm seeing this funny thing where an EFI region changes when we enter
efi_enter_virtual_mode when booting with edk2 on kvm.
On 08/05/13 15:02, Borislav Petkov wrote:
On Mon, Aug 05, 2013 at 01:27:16PM +0200, Laszlo Ersek wrote:
--- before 2013-07-31 22:20:52.316039492 +0200
+++ after 2013-07-31 22:21:30.960731706 +0200
@@ -9,7 +9,7 @@ efi: mem07: type=2, attr=0xf, range=[0x0
efi: mem08: type=7, attr
On 08/05/13 16:03, Borislav Petkov wrote:
On Mon, Aug 05, 2013 at 03:39:31PM +0200, Laszlo Ersek wrote:
My question was: is my understanding correct that you only see this
problem with -enable-kvm? Because,
On 08/01/13 18:49, Borislav Petkov wrote:
so I'm seeing this funny thing where an EFI
On 08/05/13 16:40, Borislav Petkov wrote:
On Mon, Aug 05, 2013 at 04:27:44PM +0200, Laszlo Ersek wrote:
I wouldn't call the design of SetVirtualAddressMap() braindead.
Ok, I've always wondered and you could probably shed some light on the
matter: why is SetVirtualAddressMap() a call-once
On 08/05/13 18:47, Borislav Petkov wrote:
On Mon, Aug 05, 2013 at 06:41:20PM +0200, Laszlo Ersek wrote:
I didn't realize the timestamps survive kexec. (As far as I remember
the kernels I played with kexec on didn't have the automatic
timestamps yet in dmesg, but I might have messed up just
On 08/05/13 18:47, Borislav Petkov wrote:
Here's the whole dmesg up until efi_enter_virtual_map. When we have entered
efi_enter_virtual_mode, the region has changed from
[0.00] efi: mem11: type=4, attr=0xf,
range=[0x7e0ad000-0x7e0cc000) (0MB)
to
[0.023004]
On 08/05/13 23:41, Borislav Petkov wrote:
On Mon, Aug 05, 2013 at 02:37:08PM -0700, H. Peter Anvin wrote:
All of this would be a non-problem if there weren't buggy
implementations which can't run *without* SetVirtualAddressMap().
Oh, you mean, if we were to call the runtime services through
On 09/16/13 12:59, Matt Fleming wrote:
On Fri, 13 Sep, at 02:38:12PM, jerry.hoem...@hp.com wrote:
Matt,
We have hit an issue on our new platform in development related to the
call of efi_reserve_boot_services() from setup_arch().
The reservation can interfere with allocation of the crash
On 09/16/13 17:57, Josh Triplett wrote:
The edk2 commit that flipped the memory type underneath the image data
from EfiReservedMemoryType to EfiBootServicesData is:
https://github.com/tianocore/edk2/commit/4c58575e
I think this commit is wrong. It's fine for OSPM to release the image
On 08/20/14 22:30, Matt Fleming wrote:
[ Pulling in EDK2 folks for help ]
On Wed, 20 Aug, at 08:53:45PM, Michael Brown wrote:
On 20/08/14 20:05, Mantas Mikulėnas wrote:
I experimented with some things (like setting chunk size to a few kB
to see if it hangs earlier or only at the very end;
in order to match the kernel coding
style more closely. The element size is tightened from 32 to 20 bytes
(maximum actual string length + 1) so that we can derive the field width
from the element size.
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
include/linux/efi.h| 7 ++
drivers
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
arch/ia64/kernel/efi.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c
index 741b99c..c52d754 100644
--- a/arch/ia64/kernel/efi.c
+++ b/arch/ia64/kernel/efi.c
@@ -568,6
Add the following macro from the UEFI spec, for completeness:
EFI_MEMORY_UCE Memory cacheability attribute: The memory region
supports being configured as not cacheable, exported,
and supports the fetch and add semaphore mechanism.
Signed-off-by: Laszlo
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
arch/arm64/kernel/efi.c | 26 ++
1 file changed, 6 insertions(+), 20 deletions(-)
diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index 03aaa99..3b1f23c 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
arch/x86/platform/efi/efi.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 850da94..ae2573a 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86
)
[0.00] efi: mem34: [Conventional Memory| | | | | |WB|WT|WC|UC]
range=[0x07ff-0x0800) (0MB)
I can't test the series on ia64.
Thanks,
Laszlo
Laszlo Ersek (5):
efi: add macro for EFI_MEMORY_UCE memory attribute
efi: introduce efi_md_typeattr_format()
x86: efi
On 09/01/14 09:22, Ingo Molnar wrote:
* Laszlo Ersek ler...@redhat.com wrote:
It's a pain to analyze EFI memmap logs while debugging, especially to
verify the memory types (an enum) and the memory attributes (a bitmap).
This series renders those columns human-readable, and unifies
Add the following macro from the UEFI spec, for completeness:
EFI_MEMORY_UCE Memory cacheability attribute: The memory region
supports being configured as not cacheable, exported,
and supports the fetch and add semaphore mechanism.
Signed-off-by: Laszlo
-readable, and unifies
their formatting between x86, ia64 and arm64.
Thanks
Laszlo
Laszlo Ersek (5):
efi: add macro for EFI_MEMORY_UCE memory attribute
efi: introduce efi_md_typeattr_format()
x86: efi: format EFI memory type attrs with efi_md_typeattr_format()
ia64: efi: format EFI memory
in order to match the kernel coding
style more closely. The element size is tightened from 32 to 20 bytes
(maximum actual string length + 1) so that we can derive the field width
from the element size.
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
include/linux/efi.h| 7 ++
drivers
On 09/03/14 15:01, Ard Biesheuvel wrote:
On 3 September 2014 13:32, Laszlo Ersek ler...@redhat.com wrote:
changes in v2:
- explain with examples how the log's appearance changes, in patches 3-5
[Ingo]
v1 blurb:
It's a pain to analyze EFI memmap logs while debugging, especially to
verify
On 09/03/14 15:18, Matt Fleming wrote:
On Wed, 03 Sep, at 03:01:31PM, Ard Biesheuvel wrote:
Tested-by: Ard Biesheuvel ard.biesheu...@linaro.org
(on arm64 only)
+1 for aligning between architectures
+1 for cleaning up the output to make it more readable
Thanks Ard.
Ah, apologies for
On 09/05/14 19:03, Yinghai Lu wrote:
On Thu, Sep 4, 2014 at 11:38 PM, Laszlo Ersek ler...@redhat.com wrote:
On 09/05/14 07:47, Anders Darander wrote:
In other words, the rounding up of the kernel will be undone in a
somewhat higher level driver in the firmware, and the request size
On 12/09/14 10:58, Borislav Petkov wrote:
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
On 01/30/15 17:43, Borislav Petkov wrote:
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
On 01/05/15 15:03, Matt Fleming wrote:
On Wed, 10 Dec, at 11:46:28AM, Borislav Petkov wrote:
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
http://people.redhat.com/~lersek/ovmf-whitepaper-c770f8c.txt
(An official Red Hat whitepaper PDF edition, for graphical displays, is
in the works. As time and technical hurdles allow, both the plain text
and the PDF editions shall appear under
http://www.linux-kvm.org/page/OVMF too, replacing the
)0x0002ULL)/*
read-only */
#define EFI_MEMORY_RUNTIME ((u64)0x8000ULL)/* range
requires runtime mapping */
#define EFI_MEMORY_DESCRIPTOR_VERSION1
Reviewed-by: Laszlo Ersek ler...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe linux-efi
... and so linux-efi finally has a public archive again (because GMANE
has been defunct for a while now):
https://www.mail-archive.com/linux-efi@vger.kernel.org/
Whoever administers this list, please consider updating the info box at:
http://vger.kernel.org/vger-lists.html#linux-efi
--*--
On 06/15/18 12:48, Ard Biesheuvel wrote:
> KVM guests on ARM have special requirements when it comes to mapping
> framebuffers: given that the host [emulating the framebuffer] uses
> cacheable accesses to read from the framebuffer region, the guest
> should uses cacheable accesses as well, or
fc62d6a, using the F28 kernel config. I didn't pass
any parameters to efifb. The series works perfectly for me.
Tested-by: Laszlo Ersek
Thanks!
Laszlo
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
;
> The main user of this driver is the fwts [0] tool that already checks if
> the effective user ID is 0 and fails otherwise. So this change shouldn't
> cause any regression to this tool.
>
> [0]: https://wiki.ubuntu.com/FirmwareTestSuite/Reference/uefivarinfo
>
> Signed-off-
igned
> int cmd,
>
> static int efi_test_open(struct inode *inode, struct file *file)
> {
> + if (!capable(CAP_SYS_ADMIN))
> + return -EACCES;
> /*
>* nothing special to do here
>* We do accept multiple open files at the same time as we
>
Looks consistent with other capable(CAP_SYS_ADMIN) checks in
drivers/firmware/efi/.
Acked-by: Laszlo Ersek
Thanks!
Laszlo
33 matches
Mail list logo
