Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]

Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]

[Thomas Meyer]

Hi.

For the record. Feedback is welcome. But i guess we stick with Edgars
solution.

PS: Where do i get the PCI firmware specification for free?

My idea was that the EFI memory map doesn't explicitly reserve all not
used memory, because the PCI MCFG memory area isn't listed in the EFI
memory map. but this seems to be a bug?!


diff --git a/arch/i386/kernel/efi.c b/arch/i386/kernel/efi.c
index fe15804..4a81f35 100644
--- a/arch/i386/kernel/efi.c
+++ b/arch/i386/kernel/efi.c
@@ -39,7 +39,7 @@ #include <asm/processor.h>
 #include <asm/desc.h>
 #include <asm/tlbflush.h>

-#define EFI_DEBUG      0
+#define EFI_DEBUG      1
 #define PFX            "EFI: "

 extern efi_status_t asmlinkage efi_call_phys(void *, ...);
@@ -649,3 +649,27 @@ u64 efi_mem_attributes(unsigned long phy
        }
        return 0;
 }
+
+int efi_is_free(unsigned long s, unsigned long e)
+{
+
+       int i;
+       efi_memory_desc_t *md;
+       void *p;
+
+       for (p = memmap.map, i = 0; p < memmap.map_end; p +=
memmap.desc_size, i++) {
+               md = p;
+               /* is the region (part) in overlap with the current
region ?*/
+               if (md->phys_addr >= e || md->phys_addr + (md->num_pages
<< EFI_PAGE_SHIFT) <= s) {
+                       continue;
+               } else {
+                       if (md->type == EFI_MEMORY_MAPPED_IO) {
+                               printk("EFI: memmap entry: %i is already
mapped!\n", i);
+                       } else {
+                               printk("EFI: MCFG blocking memmap entry:
%i\n", i);
+                               return 0;
+                       }
+               }
+       }
+       return 1;
+}
diff --git a/arch/i386/pci/mmconfig.c b/arch/i386/pci/mmconfig.c
index e545b09..bcf4665 100644
--- a/arch/i386/pci/mmconfig.c
+++ b/arch/i386/pci/mmconfig.c
@@ -13,6 +13,7 @@ #include <linux/pci.h>
 #include <linux/init.h>
 #include <linux/acpi.h>
 #include <asm/e820.h>
+#include <linux/efi.h>
 #include "pci.h"

 /* aperture is up to 256MB but BIOS may reserve less */
@@ -198,13 +199,23 @@ void __init pci_mmcfg_init(void)
            (pci_mmcfg_config[0].base_address == 0))
                return;

-       if (!e820_all_mapped(pci_mmcfg_config[0].base_address,
-                       pci_mmcfg_config[0].base_address +
MMCONFIG_APER_MIN,
-                       E820_RESERVED)) {
-               printk(KERN_ERR "PCI: BIOS Bug: MCFG area at %x is not
E820-reserved\n",
-                               pci_mmcfg_config[0].base_address);
-               printk(KERN_ERR "PCI: Not using MMCONFIG.\n");
-               return;
+       if (efi_enabled) {
+               if (!efi_is_free(pci_mmcfg_config[0].base_address,
+                               pci_mmcfg_config[0].base_address +
MMCONFIG_APER_MIN)) {
+                       printk(KERN_ERR "PCI: EFI: memory region at %x
is already in use!\n",
+
pci_mmcfg_config[0].base_address);
+                       printk(KERN_ERR "PCI: Not using MMCONFIG.\n");
+                       return;
+               }
+       } else {
+               if (!e820_all_mapped(pci_mmcfg_config[0].base_address,
+                               pci_mmcfg_config[0].base_address +
MMCONFIG_APER_MIN,
+                               E820_RESERVED)) {
+                       printk(KERN_ERR "PCI: BIOS Bug: MCFG area at %x
is not E820-reserved.\n",
+
pci_mmcfg_config[0].base_address);
+                       printk(KERN_ERR "PCI: Not using MMCONFIG.\n");
+                       return;
+               }
        }

        printk(KERN_INFO "PCI: Using MMCONFIG\n");
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 66d621d..7dffbf9 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -302,6 +302,7 @@ extern void efi_initialize_iomem_resourc
                                        struct resource *data_resource);
 extern unsigned long __init efi_get_time(void);
 extern int __init efi_set_rtc_mmss(unsigned long nowtime);
+extern int efi_is_free(unsigned long s, unsigned long e);
 extern struct efi_memory_map memmap;

 /**

Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]

[Edgar Hucek]

Rajesh's patch does not solve my problem. Actually i work on a force patch.

cu

Edgar

Chuck Ebbert schrieb:
> In-Reply-To: <Pine.LNX.4.64.0607131507220.5623@g5.osdl.org>
> 
> On Thu, 13 Jul 2006 15:15:21 -0700, Linus Torvalds wrote:
> 
>>> From kernel 2.6.16 to kernel 2.6.17 a new check is made.
>>> File arch/i386/pci/mmconfig.c -> funktion pci_mmcfg_init -> check e820_all_mapped
>>> The courios thing is that this check will always fail on the
>>> Intel Macs booted through efi. Parsing of the ACPI_MCFG table
>>> returns e0000000 for the start. But this location is
>>> not in the memory map which the efi firmware have :
>>> BIOS-EFI: 00000000e00f8000 - 00000000e00f9000 (reserved)
>> It _sounds_ like you may not have converted all the EFI types 
>> (EFI_UNUSABLE_MEMORY?), but regardless, I think it would be fine to have 
>> perhaps a "PCI_FORCE_MMCONF" flag that avoided that sanity check, and then 
>> you could have some code (either the EFI code _or_ some DMI code) that 
>> sets it for the Intel Macs.
>>
>> Note that the check in pci_mmcfg_init() shouldn't be some EFI hack itself, 
>> it would be a real flag for the PCI subsystem, independently of EFI (I can 
>> see it being useful for a kernel command line option, even), and the only 
>> EFI connection would be that perhaps the EFI code ends up setting that 
>> flag (especially if there is some EFI command for doing this).
>>
>> Btw, if you do do this, I think we should make sure that the MMCONFIG base 
>> address is reserved in the PCI MMIO resource structures (which we don't do 
>> now, I think - part of the whole point of verifying that it's marked as 
>> E820_RESERVED is exactly the fact that otherwise we migth have problems 
>> with PCI MMIO resource allocations allocating a regular PCI resource over 
>> the MMCONFIG space..)
> 
> I just reposted Rajesh's patch for this (fixed the one previous complaint
> from the list.)
> 
>  Subj:  [patch, take 3] PCI: use ACPI to verify extended config space on x86
> 
> Edgar, can you get it and test?
> 
> Discussion should probably continue in that thread...
> 

Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]

[Linus Torvalds]

On Fri, 14 Jul 2006, Edgar Hucek wrote:
>
> This is the memory map from the efi shell :

Ok, it really looks like EFI is broken. You said that "ACPI_MCFG table
returns e0000000", ie we should find the config space thing there, yet:

> [ snip snip ... ]
> ACPI_recl  000000007EEEF000-000000007EEFEFFF  0000000000000010 000000000000000F
> RT_data    000000007EEFF000-000000007EEFFFFF  0000000000000001 800000000000000F
> MemMapIO   00000000E00F8000-00000000E00F8FFF  0000000000000001 8000000000000000
> MemMapIO   00000000FED1C000-00000000FED1FFFF  0000000000000004 8000000000000000
> MemMapIO   00000000FFFB0000-00000000FFFDFFFF  0000000000000030 8000000000000000

It clearly wasn't there..

However, it looks like your conversion is a bit buggy:

> This is the converted memory map :
> 
> [ snip snip .. ]
>  BIOS-EFI: 000000007eeef000 - 000000007eeff000 (ACPI data)
>  BIOS-EFI: 00000000e00f8000 - 00000000e00f9000 (reserved)
>  BIOS-EFI: 00000000fed1c000 - 00000000fed20000 (reserved)
>  BIOS-EFI: 00000000fffb0000 - 00000000fffe0000 (reserved)

The above is missing the "RT_data" thing (which was there in your input):

	mem31: type=6, attr=0x800000000000000f, range=[0x000000007eeff000-0x000000007ef00000) (0MB)

> This is the funktion i used for converting :
> 
>                 case EFI_RESERVED_TYPE:
>                 case EFI_MEMORY_MAPPED_IO:
>                 case EFI_MEMORY_MAPPED_IO_PORT_SPACE:
>                 case EFI_UNUSABLE_MEMORY:
>                         add_memory_region(md->phys_addr, md->num_pages << EFI_PAGE_SHIFT, E820_RESERVED);
>                         break;

I think that should be a "default:", to make sure that you don't have any 
memory region types that get ignored. Because it looks like you missed the 
EFI_RUNTIME_SERVICES_CODE/EFI_RUNTIME_SERVICES_DATA ones at a minimum (an 
dmaybe others - I didn't check).

Anyway, that won't fix your bug, and yes, it sounds like you should add a 
PCI_PROBE_FORCE_MMCFG flag (and then do the proper MMIO region reservation 
to make sure that we don't allocate over it when allocating PCI 
resources).

Looks good otherwise.

		Linus

Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]

[Edgar Hucek]

Chuck Ebbert schrieb:
> In-Reply-To: <Pine.LNX.4.64.0607131507220.5623@g5.osdl.org>
> 
> On Thu, 13 Jul 2006 15:15:21 -0700, Linus Torvalds wrote:
> 
>>> From kernel 2.6.16 to kernel 2.6.17 a new check is made.
>>> File arch/i386/pci/mmconfig.c -> funktion pci_mmcfg_init -> check e820_all_mapped
>>> The courios thing is that this check will always fail on the
>>> Intel Macs booted through efi. Parsing of the ACPI_MCFG table
>>> returns e0000000 for the start. But this location is
>>> not in the memory map which the efi firmware have :
>>> BIOS-EFI: 00000000e00f8000 - 00000000e00f9000 (reserved)
>> It _sounds_ like you may not have converted all the EFI types 
>> (EFI_UNUSABLE_MEMORY?), but regardless, I think it would be fine to have 
>> perhaps a "PCI_FORCE_MMCONF" flag that avoided that sanity check, and then 
>> you could have some code (either the EFI code _or_ some DMI code) that 
>> sets it for the Intel Macs.
>>
>> Note that the check in pci_mmcfg_init() shouldn't be some EFI hack itself, 
>> it would be a real flag for the PCI subsystem, independently of EFI (I can 
>> see it being useful for a kernel command line option, even), and the only 
>> EFI connection would be that perhaps the EFI code ends up setting that 
>> flag (especially if there is some EFI command for doing this).
>>
>> Btw, if you do do this, I think we should make sure that the MMCONFIG base 
>> address is reserved in the PCI MMIO resource structures (which we don't do 
>> now, I think - part of the whole point of verifying that it's marked as 
>> E820_RESERVED is exactly the fact that otherwise we migth have problems 
>> with PCI MMIO resource allocations allocating a regular PCI resource over 
>> the MMCONFIG space..)
> 
> I just reposted Rajesh's patch for this (fixed the one previous complaint
> from the list.)
> 
>  Subj:  [patch, take 3] PCI: use ACPI to verify extended config space on x86
> 
> Edgar, can you get it and test?
> 
> Discussion should probably continue in that thread...
> 

I can't find the patch, can you send it ?

cu

Edgar

Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]

[Chuck Ebbert]

In-Reply-To: <Pine.LNX.4.64.0607131507220.5623@g5.osdl.org>

On Thu, 13 Jul 2006 15:15:21 -0700, Linus Torvalds wrote:

> > From kernel 2.6.16 to kernel 2.6.17 a new check is made.
> > File arch/i386/pci/mmconfig.c -> funktion pci_mmcfg_init -> check e820_all_mapped
> > The courios thing is that this check will always fail on the
> > Intel Macs booted through efi. Parsing of the ACPI_MCFG table
> > returns e0000000 for the start. But this location is
> > not in the memory map which the efi firmware have :
> > BIOS-EFI: 00000000e00f8000 - 00000000e00f9000 (reserved)
> 
> It _sounds_ like you may not have converted all the EFI types 
> (EFI_UNUSABLE_MEMORY?), but regardless, I think it would be fine to have 
> perhaps a "PCI_FORCE_MMCONF" flag that avoided that sanity check, and then 
> you could have some code (either the EFI code _or_ some DMI code) that 
> sets it for the Intel Macs.
> 
> Note that the check in pci_mmcfg_init() shouldn't be some EFI hack itself, 
> it would be a real flag for the PCI subsystem, independently of EFI (I can 
> see it being useful for a kernel command line option, even), and the only 
> EFI connection would be that perhaps the EFI code ends up setting that 
> flag (especially if there is some EFI command for doing this).
> 
> Btw, if you do do this, I think we should make sure that the MMCONFIG base 
> address is reserved in the PCI MMIO resource structures (which we don't do 
> now, I think - part of the whole point of verifying that it's marked as 
> E820_RESERVED is exactly the fact that otherwise we migth have problems 
> with PCI MMIO resource allocations allocating a regular PCI resource over 
> the MMCONFIG space..)

I just reposted Rajesh's patch for this (fixed the one previous complaint
from the list.)

 Subj:  [patch, take 3] PCI: use ACPI to verify extended config space on x86

Edgar, can you get it and test?

Discussion should probably continue in that thread...

-- 
Chuck
 "You can't read a newspaper if you can't read."  --George W. Bush

Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]

[H. Peter Anvin]

Eric W. Biederman wrote:
> 
> While we are thinking about this I have a stupid question.
> Currently if a memory mapped region does not fall in a standard PCI
> bar we insist it must be E820 reserved.  However if we E820 reserve
> the memory of a standard pci bar it becomes unusable.
> 
> Is this really the behavior that we intend?
> 
> It gets confusing that E820 reserved gets double duty as memory
> the BIOS is using and MMIO space that is mapped by a non-standard bar.
> 

Well, they are both really the same thing... "memory space the OS has no 
idea how it works; here there be dragons."

	-hpa

Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]

[Edgar Hucek]

This is the memory map from the efi shell :

available  0000000000000000-000000000008EFFF  000000000000008F 000000000000000F
ACPI_NVS   000000000008F000-000000000008FFFF  0000000000000001 000000000000000F
available  0000000000090000-000000000009FFFF  0000000000000010 000000000000000F
available  0000000000100000-000000007C64FFFF  000000000007C550 000000000000000F
BS_data    000000007C650000-000000007C697FFF  0000000000000048 000000000000000F
available  000000007C698000-000000007CEA9FFF  0000000000000812 000000000000000F
LoaderData 000000007CEAA000-000000007CEC2FFF  0000000000000019 000000000000000F
LoaderCode 000000007CEC3000-000000007CFD5FFF  0000000000000113 000000000000000F
LoaderData 000000007CFD6000-000000007D08DFFF  00000000000000B8 000000000000000F
LoaderCode 000000007D08E000-000000007D09EFFF  0000000000000011 000000000000000F
available  000000007D09F000-000000007D37DFFF  00000000000002DF 000000000000000F
BS_data    000000007D37E000-000000007DCF0FFF  0000000000000973 000000000000000F
available  000000007DCF1000-000000007DD2EFFF  000000000000003E 000000000000000F
BS_data    000000007DD2F000-000000007DDD7FFF  00000000000000A9 000000000000000F
available  000000007DDD8000-000000007DE10FFF  0000000000000039 000000000000000F
BS_data    000000007DE11000-000000007E0D0FFF  00000000000002C0 000000000000000F
ACPI_NVS   000000007E0D1000-000000007E2D1FFF  0000000000000201 000000000000000F
BS_data    000000007E2D2000-000000007ECEDFFF  0000000000000A1C 000000000000000F
available  000000007ECEE000-000000007ED30FFF  0000000000000043 000000000000000F
BS_code    000000007ED31000-000000007EE3FFFF  000000000000010F 000000000000000F
available  000000007EE40000-000000007EE48FFF  0000000000000009 000000000000000F
RT_code    000000007EE49000-000000007EE6EFFF  0000000000000026 800000000000000F
available  000000007EE6F000-000000007EE7EFFF  0000000000000010 000000000000000F
RT_data    000000007EE7F000-000000007EEAAFFF  000000000000002C 800000000000000F
available  000000007EEAB000-000000007EEBAFFF  0000000000000010 000000000000000F
ACPI_recl  000000007EEBB000-000000007EEBFFFF  0000000000000005 000000000000000F
available  000000007EEC0000-000000007EEC1FFF  0000000000000002 000000000000000F
ACPI_NVS   000000007EEC2000-000000007EEEEFFF  000000000000002D 000000000000000F
ACPI_recl  000000007EEEF000-000000007EEFEFFF  0000000000000010 000000000000000F
RT_data    000000007EEFF000-000000007EEFFFFF  0000000000000001 800000000000000F
MemMapIO   00000000E00F8000-00000000E00F8FFF  0000000000000001 8000000000000000
MemMapIO   00000000FED1C000-00000000FED1FFFF  0000000000000004 8000000000000000
MemMapIO   00000000FFFB0000-00000000FFFDFFFF  0000000000000030 8000000000000000

This is the Memory what the kernel efi funktions get :

mem00: type=7, attr=0xf, range=[0x0000000000000000-0x000000000008f000) (0MB)
mem01: type=10, attr=0xf, range=[0x000000000008f000-0x0000000000090000) (0MB)
mem02: type=7, attr=0xf, range=[0x0000000000090000-0x00000000000a0000) (0MB)
mem03: type=2, attr=0xf, range=[0x0000000000100000-0x0000000003300000) (50MB)
mem04: type=7, attr=0xf, range=[0x0000000003300000-0x000000007c650000) (1939MB)
mem05: type=4, attr=0xf, range=[0x000000007c650000-0x000000007c698000) (0MB)
mem06: type=7, attr=0xf, range=[0x000000007c698000-0x000000007cf9a000) (9MB)
mem07: type=2, attr=0xf, range=[0x000000007cf9a000-0x000000007cfa5000) (0MB)
mem08: type=1, attr=0xf, range=[0x000000007cfa5000-0x000000007cfd6000) (0MB)
mem09: type=2, attr=0xf, range=[0x000000007cfd6000-0x000000007d032000) (0MB)
mem10: type=1, attr=0xf, range=[0x000000007d032000-0x000000007d033000) (0MB)
mem11: type=7, attr=0xf, range=[0x000000007d033000-0x000000007d034000) (0MB)
mem12: type=2, attr=0xf, range=[0x000000007d034000-0x000000007d08e000) (0MB)
mem13: type=1, attr=0xf, range=[0x000000007d08e000-0x000000007d09f000) (0MB)
mem14: type=7, attr=0xf, range=[0x000000007d09f000-0x000000007d3bf000) (3MB)
mem15: type=4, attr=0xf, range=[0x000000007d3bf000-0x000000007dcf1000) (9MB)
mem16: type=7, attr=0xf, range=[0x000000007dcf1000-0x000000007ddc1000) (0MB)
mem17: type=4, attr=0xf, range=[0x000000007ddc1000-0x000000007e0d1000) (3MB)
mem18: type=10, attr=0xf, range=[0x000000007e0d1000-0x000000007e2d2000) (2MB)
mem19: type=4, attr=0xf, range=[0x000000007e2d2000-0x000000007ecee000) (10MB)
mem20: type=7, attr=0xf, range=[0x000000007ecee000-0x000000007ed31000) (0MB)
mem21: type=3, attr=0xf, range=[0x000000007ed31000-0x000000007ee40000) (1MB)
mem22: type=7, attr=0xf, range=[0x000000007ee40000-0x000000007ee49000) (0MB)
mem23: type=5, attr=0x800000000000000f, range=[0x000000007ee49000-0x000000007ee6f000) (0MB)
mem24: type=7, attr=0xf, range=[0x000000007ee6f000-0x000000007ee7f000) (0MB)
mem25: type=6, attr=0x800000000000000f, range=[0x000000007ee7f000-0x000000007eeab000) (0MB)
mem26: type=7, attr=0xf, range=[0x000000007eeab000-0x000000007eebb000) (0MB)
mem27: type=9, attr=0xf, range=[0x000000007eebb000-0x000000007eec0000) (0MB)
mem28: type=7, attr=0xf, range=[0x000000007eec0000-0x000000007eec2000) (0MB)
mem29: type=10, attr=0xf, range=[0x000000007eec2000-0x000000007eeef000) (0MB)
mem30: type=9, attr=0xf, range=[0x000000007eeef000-0x000000007eeff000) (0MB)
mem31: type=6, attr=0x800000000000000f, range=[0x000000007eeff000-0x000000007ef00000) (0MB)
mem32: type=11, attr=0x8000000000000000, range=[0x00000000e00f8000-0x00000000e00f9000) (0MB)
mem33: type=11, attr=0x8000000000000000, range=[0x00000000fed1c000-0x00000000fed20000) (0MB)
mem34: type=11, attr=0x8000000000000000, range=[0x00000000fffb0000-0x00000000fffe0000) (0MB)

This is the converted memory map :


 BIOS-EFI: 0000000000000000 - 000000000008f000 (usable)
 BIOS-EFI: 000000000008f000 - 0000000000090000 (ACPI NVS)
 BIOS-EFI: 0000000000090000 - 00000000000a0000 (usable)
 BIOS-EFI: 0000000003300000 - 000000007c650000 (usable)
 BIOS-EFI: 000000007c698000 - 000000007cf9a000 (usable)
 BIOS-EFI: 000000007d033000 - 000000007d034000 (usable)
 BIOS-EFI: 000000007d09f000 - 000000007d3bf000 (usable)
 BIOS-EFI: 000000007dcf1000 - 000000007ddc1000 (usable)
 BIOS-EFI: 000000007e0d1000 - 000000007e2d2000 (ACPI NVS)
 BIOS-EFI: 000000007ecee000 - 000000007ed31000 (usable)
 BIOS-EFI: 000000007ee40000 - 000000007ee49000 (usable)
 BIOS-EFI: 000000007ee6f000 - 000000007ee7f000 (usable)
 BIOS-EFI: 000000007eeab000 - 000000007eebb000 (usable)
 BIOS-EFI: 000000007eebb000 - 000000007eec0000 (ACPI data)
 BIOS-EFI: 000000007eec0000 - 000000007eec2000 (usable)
 BIOS-EFI: 000000007eec2000 - 000000007eeef000 (ACPI NVS)
 BIOS-EFI: 000000007eeef000 - 000000007eeff000 (ACPI data)
 BIOS-EFI: 00000000e00f8000 - 00000000e00f9000 (reserved)
 BIOS-EFI: 00000000fed1c000 - 00000000fed20000 (reserved)
 BIOS-EFI: 00000000fffb0000 - 00000000fffe0000 (reserved)

This is the funktion i used for converting :

void __init efi_init_e820_map(void)
{
        efi_memory_desc_t *md;
        unsigned long long start = 0;
        unsigned long long end = 0;
        unsigned long long size = 0;
        void *p;

        e820.nr_map = 0;

        for (p = memmap.map; p < memmap.map_end;
                p += memmap.desc_size) {
                md = p;
                switch (md->type) {
                case EFI_ACPI_RECLAIM_MEMORY:
                        add_memory_region(md->phys_addr, md->num_pages << EFI_PAGE_SHIFT, E820_ACPI);
                        break;
                case EFI_RESERVED_TYPE:
                case EFI_MEMORY_MAPPED_IO:
                case EFI_MEMORY_MAPPED_IO_PORT_SPACE:
                case EFI_UNUSABLE_MEMORY:
                        add_memory_region(md->phys_addr, md->num_pages << EFI_PAGE_SHIFT, E820_RESERVED);
                        break;
                case EFI_CONVENTIONAL_MEMORY:
                        start = md->phys_addr;
                        size = md->num_pages << EFI_PAGE_SHIFT;
                        end = start + size;
                        if (start < 0x100000ULL && end > 0xA0000ULL) {
                                if (start < 0xA0000ULL)
                                        add_memory_region(start, 0xA0000ULL-start, E820_RAM);
                                if (end <= 0x100000ULL)
                                        continue;
                                start = 0x100000ULL;
                                size = end - start;
                        }
                        add_memory_region(start, size, E820_RAM);
                        break;
                case EFI_ACPI_MEMORY_NVS:
                        add_memory_region(md->phys_addr, md->num_pages << EFI_PAGE_SHIFT, E820_NVS);
                        break;
                }
        }
}


cu

Edgar Hucek


Linus Torvalds schrieb:
> 
> On Thu, 13 Jul 2006, Edgar Hucek wrote:
>> I converted the efi memory map to use the e820 table.
>> While converting i discovered why the kernel would allways
>> fail to boot through efi on Intel Macs without a proper fix.
> 
> Ok, can you show what the converted and the original map looks like?
> 
>> From kernel 2.6.16 to kernel 2.6.17 a new check is made.
>> File arch/i386/pci/mmconfig.c -> funktion pci_mmcfg_init -> check e820_all_mapped
>> The courios thing is that this check will always fail on the
>> Intel Macs booted through efi. Parsing of the ACPI_MCFG table
>> returns e0000000 for the start. But this location is
>> not in the memory map which the efi firmware have :
>> BIOS-EFI: 00000000e00f8000 - 00000000e00f9000 (reserved)
> 
> It _sounds_ like you may not have converted all the EFI types 
> (EFI_UNUSABLE_MEMORY?), but regardless, I think it would be fine to have 
> perhaps a "PCI_FORCE_MMCONF" flag that avoided that sanity check, and then 
> you could have some code (either the EFI code _or_ some DMI code) that 
> sets it for the Intel Macs.
> 
> Note that the check in pci_mmcfg_init() shouldn't be some EFI hack itself, 
> it would be a real flag for the PCI subsystem, independently of EFI (I can 
> see it being useful for a kernel command line option, even), and the only 
> EFI connection would be that perhaps the EFI code ends up setting that 
> flag (especially if there is some EFI command for doing this).
> 
> Btw, if you do do this, I think we should make sure that the MMCONFIG base 
> address is reserved in the PCI MMIO resource structures (which we don't do 
> now, I think - part of the whole point of verifying that it's marked as 
> E820_RESERVED is exactly the fact that otherwise we migth have problems 
> with PCI MMIO resource allocations allocating a regular PCI resource over 
> the MMCONFIG space..)
> 
> 			Linus
> 

Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]

[Eric W. Biederman]

Linus Torvalds <torvalds@osdl.org> writes:

> On Thu, 13 Jul 2006, Edgar Hucek wrote:
>>
>> I converted the efi memory map to use the e820 table.
>> While converting i discovered why the kernel would allways
>> fail to boot through efi on Intel Macs without a proper fix.
>
> Ok, can you show what the converted and the original map looks like?
>
>> From kernel 2.6.16 to kernel 2.6.17 a new check is made.
>> File arch/i386/pci/mmconfig.c -> funktion pci_mmcfg_init -> check
> e820_all_mapped
>> The courios thing is that this check will always fail on the
>> Intel Macs booted through efi. Parsing of the ACPI_MCFG table
>> returns e0000000 for the start. But this location is
>> not in the memory map which the efi firmware have :
>> BIOS-EFI: 00000000e00f8000 - 00000000e00f9000 (reserved)
>
> It _sounds_ like you may not have converted all the EFI types 
> (EFI_UNUSABLE_MEMORY?), but regardless, I think it would be fine to have 
> perhaps a "PCI_FORCE_MMCONF" flag that avoided that sanity check, and then 
> you could have some code (either the EFI code _or_ some DMI code) that 
> sets it for the Intel Macs.
>
> Note that the check in pci_mmcfg_init() shouldn't be some EFI hack itself, 
> it would be a real flag for the PCI subsystem, independently of EFI (I can 
> see it being useful for a kernel command line option, even), and the only 
> EFI connection would be that perhaps the EFI code ends up setting that 
> flag (especially if there is some EFI command for doing this).
>
> Btw, if you do do this, I think we should make sure that the MMCONFIG base 
> address is reserved in the PCI MMIO resource structures (which we don't do 
> now, I think - part of the whole point of verifying that it's marked as 
> E820_RESERVED is exactly the fact that otherwise we migth have problems 
> with PCI MMIO resource allocations allocating a regular PCI resource over 
> the MMCONFIG space..)

While we are thinking about this I have a stupid question.
Currently if a memory mapped region does not fall in a standard PCI
bar we insist it must be E820 reserved.  However if we E820 reserve
the memory of a standard pci bar it becomes unusable.

Is this really the behavior that we intend?

It gets confusing that E820 reserved gets double duty as memory
the BIOS is using and MMIO space that is mapped by a non-standard bar.

Eric

Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]

[Linus Torvalds]

On Thu, 13 Jul 2006, Edgar Hucek wrote:
>
> I converted the efi memory map to use the e820 table.
> While converting i discovered why the kernel would allways
> fail to boot through efi on Intel Macs without a proper fix.

Ok, can you show what the converted and the original map looks like?

> From kernel 2.6.16 to kernel 2.6.17 a new check is made.
> File arch/i386/pci/mmconfig.c -> funktion pci_mmcfg_init -> check e820_all_mapped
> The courios thing is that this check will always fail on the
> Intel Macs booted through efi. Parsing of the ACPI_MCFG table
> returns e0000000 for the start. But this location is
> not in the memory map which the efi firmware have :
> BIOS-EFI: 00000000e00f8000 - 00000000e00f9000 (reserved)

It _sounds_ like you may not have converted all the EFI types 
(EFI_UNUSABLE_MEMORY?), but regardless, I think it would be fine to have 
perhaps a "PCI_FORCE_MMCONF" flag that avoided that sanity check, and then 
you could have some code (either the EFI code _or_ some DMI code) that 
sets it for the Intel Macs.

Note that the check in pci_mmcfg_init() shouldn't be some EFI hack itself, 
it would be a real flag for the PCI subsystem, independently of EFI (I can 
see it being useful for a kernel command line option, even), and the only 
EFI connection would be that perhaps the EFI code ends up setting that 
flag (especially if there is some EFI command for doing this).

Btw, if you do do this, I think we should make sure that the MMCONFIG base 
address is reserved in the PCI MMIO resource structures (which we don't do 
now, I think - part of the whole point of verifying that it's marked as 
E820_RESERVED is exactly the fact that otherwise we migth have problems 
with PCI MMIO resource allocations allocating a regular PCI resource over 
the MMCONFIG space..)

			Linus

Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]

[Edgar Hucek]

I converted the efi memory map to use the e820 table.
While converting i discovered why the kernel would allways
fail to boot through efi on Intel Macs without a proper fix.

>From kernel 2.6.16 to kernel 2.6.17 a new check is made.
File arch/i386/pci/mmconfig.c -> funktion pci_mmcfg_init -> check e820_all_mapped
The courios thing is that this check will always fail on the
Intel Macs booted through efi. Parsing of the ACPI_MCFG table
returns e0000000 for the start. But this location is
not in the memory map which the efi firmware have :
BIOS-EFI: 00000000e00f8000 - 00000000e00f9000 (reserved)
So the e820_all_mapped would allways fail.
Anny suggestions how to fix this problem ? Maybe some kind
of whitelisting, using dmi_check_system ?

cu

Edgar Hucek


Eric W. Biederman schrieb:
> Edgar Hucek <hostmaster@ed-soft.at> writes:
> 
>> I agre with you to make efi use the e820 map as a long term solution.
>> But at the moment the efi part is completley broken without my patch.
> 
> But your patch isn't a fix.  It is a hack to make the system boot.
> 
> A patch that performed the same check on the efi memory map,
> or it converted the efi memory map to use an e820 map it would be a fix.
> 
>> At least on Intel Macs. 
>> Without the patch also my Imacfb driver makes no sense, since it is 
>> for efi booted Intel Macs. 
> 
> My point is that the kernel efi support is broken.  You have just found
> the location where the bone is poking through the skin.
> 
> I am tempted to write a patch to delete the x86 efi support at this
> point.  So that it is very clear that it needs to be completely redone.
> 
> Eric
> 

Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]

[Eric W. Biederman]

Edgar Hucek <hostmaster@ed-soft.at> writes:

> I agre with you to make efi use the e820 map as a long term solution.
> But at the moment the efi part is completley broken without my patch.

But your patch isn't a fix.  It is a hack to make the system boot.

A patch that performed the same check on the efi memory map,
or it converted the efi memory map to use an e820 map it would be a fix.

> At least on Intel Macs. 
> Without the patch also my Imacfb driver makes no sense, since it is 
> for efi booted Intel Macs. 

My point is that the kernel efi support is broken.  You have just found
the location where the bone is poking through the skin.

I am tempted to write a patch to delete the x86 efi support at this
point.  So that it is very clear that it needs to be completely redone.

Eric

Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]

[Edgar Hucek]

I agre with you to make efi use the e820 map as a long term solution.
But at the moment the efi part is completley broken without my patch.
At least on Intel Macs. 
Without the patch also my Imacfb driver makes no sense, since it is 
for efi booted Intel Macs. 

cu

Edgar (gimli) Hucek

Eric W. Biederman schrieb:
> "H. Peter Anvin" <hpa@zytor.com> writes:
> 
>> Eric W. Biederman wrote:
>>
>>>> You probably don't want to put it in the bootloader.  The kernel is easier to
>>>> upgrade than the bootloader, which is easier to upgrade than the firmware, so
>> it
>>>> makes more sense for the kernel to be as self-sufficient as is possible, or
>> at
>>>> least practical.
>>> Regardless it would be nice if the efi implementation hacks were removed.
>>>
>>> My favorite is this one in init/main.c #ifdef CONFIG_X86
>>> 	if (efi_enabled)
>>> 		efi_enter_virtual_mode();
>>> #endif
>>> Which pretty much guarantees efi won't be a distro supported feature
>>> any time soon because it breaks kexec the ability of a kexec'd kernel
>>> to boot and thus crash dump support. Or it does if you ever use efi
>>> callbacks, and if you don't use efi callbacks there is no point in
>>> calling that function.  Why are efi callbacks not always done in
>>> physical mode?
>>>
>> If nothing else, they should be isolated, and in the early kernel build a
>> datastructure like the e820 data structure, so the downstream kernel doesn't
>> deal with it.
>>
>> I have no idea what the above does; it sounds to me like something that should
>> be possible to do differently, though.
> 
> Quite.
> 
> The part that is an obvious hack is that it shows up in init/main.c
> for no apparent reason.  Instead of being in architecture specific code
> since it only applies to one architecture.  ia64 which also uses efi
> doesn't need to patch init/main.c
> 
> Basically this was just an example to add to the e820 map problem of what
> a problem this code really is.
> 
> Thinking about the e820 problem.  That is in the function:
> e820_all_mapped(unsigned long s, unsigned long e, unsigned type)
> 
> Which is a test.  I believe this is the sanity check to ensure the
> pci express memory mapped configuration area is accessible.
> 
> In which case disabling the test is totally wrong,
> and I agree with Linus that we need to convert the structure.
> 
> We need to know what the BIOS's idea of the memory map is and to be
> able to query it.
> 
> Although I am surprised we could not just make that query by looking
> at the resources.  Possibly we are too early in boot.
> 
> Eric
> 

Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]

[Arjan van de Ven]

> Although I am surprised we could not just make that query by looking
> at the resources.  Possibly we are too early in boot.

the problem in this specific case is that you try to compare the
resource info (more or less, indirectly) to the memory map, and abort if
there's a discrepancy, as a sanity check against b0rked bioses. 

Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]

[Eric W. Biederman]

"H. Peter Anvin" <hpa@zytor.com> writes:

> Eric W. Biederman wrote:
>
>>>>
>>> You probably don't want to put it in the bootloader.  The kernel is easier to
>>> upgrade than the bootloader, which is easier to upgrade than the firmware, so
> it
>>> makes more sense for the kernel to be as self-sufficient as is possible, or
> at
>>> least practical.
>> Regardless it would be nice if the efi implementation hacks were removed.
>>
>> My favorite is this one in init/main.c #ifdef CONFIG_X86
>> 	if (efi_enabled)
>> 		efi_enter_virtual_mode();
>> #endif
>> Which pretty much guarantees efi won't be a distro supported feature
>> any time soon because it breaks kexec the ability of a kexec'd kernel
>> to boot and thus crash dump support. Or it does if you ever use efi
>> callbacks, and if you don't use efi callbacks there is no point in
>> calling that function.  Why are efi callbacks not always done in
>> physical mode?
>>
>
> If nothing else, they should be isolated, and in the early kernel build a
> datastructure like the e820 data structure, so the downstream kernel doesn't
> deal with it.
>
> I have no idea what the above does; it sounds to me like something that should
> be possible to do differently, though.

Quite.

The part that is an obvious hack is that it shows up in init/main.c
for no apparent reason.  Instead of being in architecture specific code
since it only applies to one architecture.  ia64 which also uses efi
doesn't need to patch init/main.c

Basically this was just an example to add to the e820 map problem of what
a problem this code really is.

Thinking about the e820 problem.  That is in the function:
e820_all_mapped(unsigned long s, unsigned long e, unsigned type)

Which is a test.  I believe this is the sanity check to ensure the
pci express memory mapped configuration area is accessible.

In which case disabling the test is totally wrong,
and I agree with Linus that we need to convert the structure.

We need to know what the BIOS's idea of the memory map is and to be
able to query it.

Although I am surprised we could not just make that query by looking
at the resources.  Possibly we are too early in boot.

Eric

Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]

[H. Peter Anvin]

Eric W. Biederman wrote:

>>>
>> You probably don't want to put it in the bootloader.  The kernel is easier to
>> upgrade than the bootloader, which is easier to upgrade than the firmware, so it
>> makes more sense for the kernel to be as self-sufficient as is possible, or at
>> least practical.
> 
> Regardless it would be nice if the efi implementation hacks were removed.
 >
> My favorite is this one in init/main.c 
> #ifdef CONFIG_X86
> 	if (efi_enabled)
> 		efi_enter_virtual_mode();
> #endif
> 
> Which pretty much guarantees efi won't be a distro supported feature
> any time soon because it breaks kexec the ability of a kexec'd kernel
> to boot and thus crash dump support. Or it does if you ever use efi
> callbacks, and if you don't use efi callbacks there is no point in
> calling that function.  Why are efi callbacks not always done in
> physical mode?
> 

If nothing else, they should be isolated, and in the early kernel build 
a datastructure like the e820 data structure, so the downstream kernel 
doesn't deal with it.

I have no idea what the above does; it sounds to me like something that 
should be possible to do differently, though.

	-hpa

Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]

[Eric W. Biederman]

"H. Peter Anvin" <hpa@zytor.com> writes:

> Linus Torvalds wrote:
>> On Tue, 27 Jun 2006, Edgar Hucek wrote:
>>> So what is your suggestion to get the working funktionality
>>> from kernel 2.6.16 back ? 2.6.17 have broken it.
>> I'd really suggest just filling in the e820 table from the EFI information
>> early at boot.
>> (Even better would be for the EFI bootloader on x86 to just fill things in
>> _as_if_ it was filling in e820 data, but that's outside of the kernel, so if
>> you want the _kernel_ to be able to handle native EFI data, do it by just
>> translating it once into e820 mode, and you're done).
>> The translation from EFI to e820 format should be very straightforward
>> indeed. I think it's pretty much the same thing with different naming.
>>
>
> You probably don't want to put it in the bootloader.  The kernel is easier to
> upgrade than the bootloader, which is easier to upgrade than the firmware, so it
> makes more sense for the kernel to be as self-sufficient as is possible, or at
> least practical.

Regardless it would be nice if the efi implementation hacks were removed.

My favorite is this one in init/main.c 
#ifdef CONFIG_X86
	if (efi_enabled)
		efi_enter_virtual_mode();
#endif

Which pretty much guarantees efi won't be a distro supported feature
any time soon because it breaks kexec the ability of a kexec'd kernel
to boot and thus crash dump support. Or it does if you ever use efi
callbacks, and if you don't use efi callbacks there is no point in
calling that function.  Why are efi callbacks not always done in
physical mode?

Eric

Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]

[H. Peter Anvin]

Linus Torvalds wrote:
> 
> On Tue, 27 Jun 2006, Edgar Hucek wrote:
>> So what is your suggestion to get the working funktionality
>> from kernel 2.6.16 back ? 2.6.17 have broken it.
> 
> I'd really suggest just filling in the e820 table from the EFI information 
> early at boot.
> 
> (Even better would be for the EFI bootloader on x86 to just fill things in 
> _as_if_ it was filling in e820 data, but that's outside of the kernel, so 
> if you want the _kernel_ to be able to handle native EFI data, do it by 
> just translating it once into e820 mode, and you're done).
> 
> The translation from EFI to e820 format should be very straightforward 
> indeed. I think it's pretty much the same thing with different naming.
> 

You probably don't want to put it in the bootloader.  The kernel is 
easier to upgrade than the bootloader, which is easier to upgrade than 
the firmware, so it makes more sense for the kernel to be as 
self-sufficient as is possible, or at least practical.

	-hpa

Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]

[Linus Torvalds]

On Tue, 27 Jun 2006, Edgar Hucek wrote:
>
> So what is your suggestion to get the working funktionality
> from kernel 2.6.16 back ? 2.6.17 have broken it.

I'd really suggest just filling in the e820 table from the EFI information 
early at boot.

(Even better would be for the EFI bootloader on x86 to just fill things in 
_as_if_ it was filling in e820 data, but that's outside of the kernel, so 
if you want the _kernel_ to be able to handle native EFI data, do it by 
just translating it once into e820 mode, and you're done).

The translation from EFI to e820 format should be very straightforward 
indeed. I think it's pretty much the same thing with different naming.

		Linus

Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]

[Edgar Hucek]

So what is your suggestion to get the working funktionality
from kernel 2.6.16 back ? 2.6.17 have broken it.

Sure, using Apples legacy support for EFI is a method to
boot linux on the Intel Macs, but not the native way. It depends
on how good their legacy emulation is and if they implement it
in future products. They could also decide to drop it.

cu

Edgar (gimli) Hucek 

Linus Torvalds schrieb:
> 
> On Mon, 26 Jun 2006, Edgar Hucek wrote:
>> Fix EFI boot on 32 bit machines with PCI Express slots.
>> Efi machines does not have an e820 memory map.
> 
> The EFI code really should fill in the e820 memory map instead fo making 
> up its own routines (and doing it badly at that).
> 
> There's nothing wrong with the e820 table, and we should consider it just 
> the "firmware memory map", and not care how it's filled in (whether it's 
> EFI or a real e820 BIOS call).
> 
> Quite frankly, right now I'm more likely to rip out the EFI code than 
> start adding even more (broken) support for it.
> 
> On the Intel Macs, upgrading the firmware turns it into a perfectly usable 
> machine.
> 
> 		Linus
> 

Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]

[Thomas Meyer]

But doesn't the whole imacfb commit only make sense while booting  
native from efi? and booting native from efi is in the moment only  
possible through this patch.

with kind regards
thomas

PS: and i can't boot via csm at the moment, because i use gpt only!  
and i don't want to mix up old style partition table and gpt like  
boot camp do.

Re: [PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]

[Linus Torvalds]

On Mon, 26 Jun 2006, Edgar Hucek wrote:
>
> Fix EFI boot on 32 bit machines with PCI Express slots.
> Efi machines does not have an e820 memory map.

The EFI code really should fill in the e820 memory map instead fo making 
up its own routines (and doing it badly at that).

There's nothing wrong with the e820 table, and we should consider it just 
the "firmware memory map", and not care how it's filled in (whether it's 
EFI or a real e820 BIOS call).

Quite frankly, right now I'm more likely to rip out the EFI code than 
start adding even more (broken) support for it.

On the Intel Macs, upgrading the firmware turns it into a perfectly usable 
machine.

		Linus

[PATCH 1/1] Fix boot on efi 32 bit Machines [try #4]

[Edgar Hucek]

Fix EFI boot on 32 bit machines with PCI Express slots.
Efi machines does not have an e820 memory map.
Without this patch a native EFI boot, on
Intel Macs, is impossible.

Signed-off-by: Edgar Hucek <hostmaster@ed-soft.at>

--- a/arch/i386/kernel/setup.c  2006-06-25 03:13:24.000000000 +0200
+++ b/arch/i386/kernel/setup.c  2006-06-25 03:13:50.000000000 +0200
@@ -975,6 +975,10 @@
        u64 start = s;
        u64 end = e;
        int i;
+
+       if (efi_enabled)
+               return 1;
+
        for (i = 0; i < e820.nr_map; i++) {
                struct e820entry *ei = &e820.map[i];
                if (type && ei->type != type)