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 Tue, 30 Jul, at 08:52:12PM, Ingo Molnar wrote:
Pulled into tip:x86/urgent, thanks Matt!
Thanks Ingo.
Any chance we can get this to Linus for -rc5? The ARM EFI boot stub
patches depend on the bug fix in this pull request.
--
Matt Fleming, Intel Open Source Technology Center
--
To
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=0xf,
On 08/05/2013 06:02 AM, Matt Fleming wrote:
On Tue, 30 Jul, at 08:52:12PM, Ingo Molnar wrote:
Pulled into tip:x86/urgent, thanks Matt!
Thanks Ingo.
Any chance we can get this to Linus for -rc5? The ARM EFI boot stub
patches depend on the bug fix in this pull request.
Yes, we should
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,
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 region changes when we
enter
On Fri, Aug 02, 2013 at 02:29:02PM -0700, Roy Franz wrote:
The ARM kernel also has an EFI stub which works largely the same way
as the x86 stub, so move the documentation out of x86 directory and
update to reflect that it is generic, and add ARM specific text.
Signed-off-by: Roy Franz
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 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 only? Why can't I
simply call it again and update
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 Mon, 2013-08-05 at 17:15 +0200, Laszlo Ersek wrote:
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 Mon, Aug 5, 2013 at 3:56 AM, Matt Fleming m...@console-pimps.org wrote:
@@ -424,6 +424,7 @@ extern void __iomem * ioremap(unsigned long offset,
unsigned long size);
extern void __iomem * ioremap_nocache (unsigned long offset, unsigned long
size);
extern void iounmap (volatile void
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 as well...)
No, no, no, kexec is not involved
On Aug 5, 2013, at 7:40 AM, Borislav Petkov b...@alien8.de 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
Boris,
A memory map entry with zero size does not look right to me.
The memory map passed into SetVirtualAddressMap() must contain the exact same
set of memory map entries that existed when ExitBootServices() was called with
a return result of EFI_SUCCESS.
When you are showing comparisons of
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 as
On Mon, Aug 05, 2013 at 08:50:17AM -0700, Andrew Fish wrote:
AFAICT EFI pre-dates kexec merge into mainline by a number of years as
SetVirtualaddressMap() was part of EFI 1.0 (previous millennium)
Ok, fair enough.
The EFI to UEFI conversion was placing EFI 1.10 into an industry
standard,
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/2013 11:12 AM, Borislav Petkov wrote:
On Mon, Aug 05, 2013 at 08:50:17AM -0700, Andrew Fish wrote:
AFAICT EFI pre-dates kexec merge into mainline by a number of years as
SetVirtualaddressMap() was part of EFI 1.0 (previous millennium)
Ok, fair enough.
The EFI to UEFI conversion
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 their
physical addresses?
--
Regards/Gruss,
On 08/05/2013 02:41 PM, 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
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 Mon, Aug 05, 2013 at 11:26:46PM +0200, Laszlo Ersek wrote:
What happens if you pass memblock=debug on the kernel command line
(see early_memblock() in mm/memblock.c)?
(I just tried it in my Fedora 19 guest, and it in fact produced the message
[0.00] efi: Could not reserve boot
On Mon, 2013-08-05 at 23:55 +0200, Laszlo Ersek wrote:
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().
On Mon, Aug 5, 2013 at 8:33 AM, Leif Lindholm leif.lindh...@linaro.org wrote:
On Mon, Aug 05, 2013 at 03:11:49PM +0100, Dave Martin wrote:
diff --git a/arch/arm/boot/compressed/head.S
b/arch/arm/boot/compressed/head.S
index 75189f1..4c70b9e 100644
--- a/arch/arm/boot/compressed/head.S
diff --git a/arch/arm/boot/compressed/head.S
b/arch/arm/boot/compressed/head.S
index 75189f1..4c70b9e 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -122,19 +122,106 @@
.arm@ Always enter in ARM state
start:
26 matches
Mail list logo
