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 "unsub
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 ca
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 imple
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/4c
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 t
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 bringin
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, 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
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 05:31:29
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 th
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 li
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 i
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 t
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 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 o
[ 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 her
[ 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/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
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 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: [0x09f0
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 whi
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 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 reser
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 th
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 servic
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 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 con
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
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 ju
-
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 SetVirtualAddressMap(
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 involv
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..
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 som
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-onc
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: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
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: typ
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,
> > range=[0x400
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
47 matches
Mail list logo
