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 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
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 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:
> >>
> >>
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
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()
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
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
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, Aug 08, 2013 at 11:17:30AM +0100, Matt Fleming wrote:
> > Is it possible to have a switch to turn off the not required behavior
> > (hiding EFI implementation bugs) so that bad platforms could be
> > detected? This would be a good thing to try on platforms at the
> > upcoming UEFI Plugfest
On Thu, Aug 08, 2013 at 11:17:30AM +0100, Matt Fleming wrote:
Is it possible to have a switch to turn off the not required behavior
(hiding EFI implementation bugs) so that bad platforms could be
detected? This would be a good thing to try on platforms at the
upcoming UEFI Plugfest hosted
On Thu, 08 Aug, at 06:46:02AM, Andrew Fish wrote:
>
> On Aug 8, 2013, at 3:17 AM, Matt Fleming 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 beings done on
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 wrote:
> On 08/07/13 17:19, Borislav Petkov wrote:
>> On Tue, Aug 06, 2013 at
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 08/08/2013 10:02 AM, Borislav Petkov wrote:
On Wed, Aug 07, 2013 at 07:49:16PM +0200, Laszlo Ersek wrote:
Now, lines 01 to 05*do not happen*.
More precisely, they don't happen in the kernel. They happen in the
firmware. Specifically, "OvmfPkg/Library/LoadLinuxLib/Linux.c".
You're booting
On Wed, Aug 07, 2013 at 07:49:16PM +0200, Laszlo Ersek wrote:
[…]
> Now, lines 01 to 05 *do not happen*.
>
> More precisely, they don't happen in the kernel. They happen in the
> firmware. Specifically, "OvmfPkg/Library/LoadLinuxLib/Linux.c".
>
> You're booting the kernel from the qemu command
On Aug 8, 2013, at 3:17 AM, Matt Fleming 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 beings done on the Linux
>> side and we don't have good tests to catch bugs
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 beings done on the Linux
> side and we don't have good tests to catch bugs in the EFI
> implementations. If the Linux loader hides
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 beings done on the Linux
side and we don't have good tests to catch bugs in the EFI
implementations. If the Linux loader hides the
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 beings done on the Linux
side and we don't have good tests
On Wed, Aug 07, 2013 at 07:49:16PM +0200, Laszlo Ersek wrote:
[…]
Now, lines 01 to 05 *do not happen*.
More precisely, they don't happen in the kernel. They happen in the
firmware. Specifically, OvmfPkg/Library/LoadLinuxLib/Linux.c.
You're booting the kernel from the qemu command line. The
On 08/08/2013 10:02 AM, Borislav Petkov wrote:
On Wed, Aug 07, 2013 at 07:49:16PM +0200, Laszlo Ersek wrote:
Now, lines 01 to 05*do not happen*.
More precisely, they don't happen in the kernel. They happen in the
firmware. Specifically, OvmfPkg/Library/LoadLinuxLib/Linux.c.
You're booting the
On Wed, Aug 07, 2013 at 02:10:28PM -0700, 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 beings done on the Linux
> side and we don't have good tests to catch bugs in the EFI
> implementations. If the
On Aug 7, 2013, at 1:19 PM, Matt Fleming wrote:
> [ 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
[ Adding Matthew for reals this time ]
On Wed, 07 Aug, at 09:19:08PM, Matt Fleming wrote:
> [ 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
[ 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
On 08/07/13 17:19, Borislav Petkov 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?
>>
>> #define
On Aug 7, 2013, at 8:19 AM, Borislav Petkov 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?
>>
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?
On 08/07/13 17:19, Borislav Petkov 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?
#define DEBUG_POOL
[ 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
[ Adding Matthew for reals this time ]
On Wed, 07 Aug, at 09:19:08PM, Matt Fleming wrote:
[ 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
On Aug 7, 2013, at 1:19 PM, Matt Fleming m...@console-pimps.org wrote:
[ 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
On Wed, Aug 07, 2013 at 02:10:28PM -0700, 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 beings done on the Linux
side and we don't have good tests to catch bugs in the EFI
implementations. If the Linux
On 08/06/13 16:10, Borislav Petkov wrote:
> On Tue, Aug 06, 2013 at 12:08:08AM +0200, Borislav Petkov wrote:
>> Ok, thanks again for finding it, I'll go and try to figure out the whole
>> mess tomorrow.
>
> Ok, some more observations:
>
> Decompressing Linux... Parsing ELF... done.
> Booting the
On Tue, Aug 06, 2013 at 12:08:08AM +0200, Borislav Petkov wrote:
> Ok, thanks again for finding it, I'll go and try to figure out the whole
> mess tomorrow.
Ok, some more observations:
Decompressing Linux... Parsing ELF... done.
Booting the kernel.
[0.00] memblock_reserve:
On 08/06/13 00:52, James Bottomley wrote:
> 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
On 08/06/13 00:52, James Bottomley wrote:
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
On Tue, Aug 06, 2013 at 12:08:08AM +0200, Borislav Petkov wrote:
Ok, thanks again for finding it, I'll go and try to figure out the whole
mess tomorrow.
Ok, some more observations:
Decompressing Linux... Parsing ELF... done.
Booting the kernel.
[0.00] memblock_reserve:
On 08/06/13 16:10, Borislav Petkov wrote:
On Tue, Aug 06, 2013 at 12:08:08AM +0200, Borislav Petkov wrote:
Ok, thanks again for finding it, I'll go and try to figure out the whole
mess tomorrow.
Ok, some more observations:
Decompressing Linux... Parsing ELF... done.
Booting the kernel.
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*
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
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
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
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?
--
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
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
>
> [
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:
> 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
-
From: Borislav Petkov [mailto:b...@alien8.de]
Sent: Monday, August 05, 2013 9:48 AM
To: Laszlo Ersek
Cc: linux-...@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 Aug 5, 2013, at 7:40 AM, 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
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
On 08/05/13 18:12, Borislav Petkov wrote:
> On Mon, Aug 05, 2013 at 05:15:38PM +0200, Laszlo Ersek wrote:
>> The current implementation (how pointers are converted) probably doesn't
>> accommodate a second call.
>>
>> Of course you want to know why SetVirtualAddressMap() was designed like
>>
Apologies in advance for my response because it diverges from the
technical stuff.
On 08/05/13 17:34, James Bottomley wrote:
> 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:
On Mon, Aug 05, 2013 at 05:15:38PM +0200, Laszlo Ersek wrote:
> The current implementation (how pointers are converted) probably doesn't
> accommodate a second call.
>
> Of course you want to know why SetVirtualAddressMap() was designed like
> that... I didn't participate in the design so I don't
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
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
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
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
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 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:
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/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 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 05:15:38PM +0200, Laszlo Ersek wrote:
The current implementation (how pointers are converted) probably doesn't
accommodate a second call.
Of course you want to know why SetVirtualAddressMap() was designed like
that... I didn't participate in the design so I don't know
Apologies in advance for my response because it diverges from the
technical stuff.
On 08/05/13 17:34, James Bottomley wrote:
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
On 08/05/13 18:12, Borislav Petkov wrote:
On Mon, Aug 05, 2013 at 05:15:38PM +0200, Laszlo Ersek wrote:
The current implementation (how pointers are converted) probably doesn't
accommodate a second call.
Of course you want to know why SetVirtualAddressMap() was designed like
that... I didn't
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-...@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().
94 matches
Mail list logo
