On Wed, 18 Sep, at 01:24:14PM, jerry.hoem...@hp.com wrote:
Matt,
I conducted the following experiments on a 3.11 kernel:
Jerry, could you paste your memory map from the kernel log?
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line
On Mon, Sep 16, 2013 at 11:59:20AM +0100, 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
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 kernel.
Jerry, thanks for bringing
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 Mon, Sep 16, 2013 at 01:50:46PM +0200, Laszlo Ersek wrote:
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
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 Mon, Sep 16, 2013 at 06:25:22PM +0200, Laszlo Ersek wrote:
Or are you alluding to UEFI firmware that's not based on TianoCore?
Most BGRT implementations are IBV specific rather than coming from
Tiano. The ACPI spec says that the image should be stored in
EfiBootServicesData, and most
On Mon, Sep 16, 2013 at 06:25:22PM +0200, Laszlo Ersek wrote:
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
On Thu, 08 Aug, at 06:46:02AM, Andrew Fish wrote:
On Aug 8, 2013, at 3:17 AM, Matt Fleming m...@console-pimps.org wrote:
On Wed, 07 Aug, at 02:10:28PM, Andrew Fish wrote:
Well the issue I see is I don't think OS X or Windows are doing this.
So I'm guessing there is some unique thing
0001-OvmfPkg-allocate-the-EFI-memory-map-for-Linux-as-Loa.patch
was applied in r14555.
Thanks for the contribution.
And thanks for the bug report testing Boris.
On Wed, Aug 7, 2013 at 10:49 AM, Laszlo Ersek ler...@redhat.com wrote:
On 08/07/13 17:19, Borislav Petkov wrote:
On Tue, Aug 06,
On Aug 7, 2013, at 8:19 AM, Borislav Petkov b...@alien8.de wrote:
On Tue, Aug 06, 2013 at 05:31:29PM +0200, Laszlo Ersek wrote:
Can you capture the OVMF debug output? Do you see
ConvertPages: Incompatible memory types
there?
Can you set the following bits too in the debug mask?
[ Readding Matthew Garrett to the Cc list, seeing as we both got removed
for some unknown reason ]
On Wed, 07 Aug, at 10:23:56AM, Andrew Fish wrote:
OK so I think I need some Cliff Notes here to help me understand what
is going on...
type 4 is EfiBootServicesData and attr 0x0f is cache
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 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/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 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 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
-
From: Borislav Petkov [mailto:b...@alien8.de]
Sent: Monday, August 05, 2013 9:48 AM
To: Laszlo Ersek
Cc: linux-efi@vger.kernel.org; Gleb Natapov; edk2-de...@lists.sourceforge.net;
lkml; David Woodhouse
Subject: Re: [edk2] Corrupted EFI region
On Mon, Aug 05, 2013 at 06:41:20PM +0200, Laszlo Ersek
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().
32 matches
Mail list logo
