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

[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)

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

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]

[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]

[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]

[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]

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:

> 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]

[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]

[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 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]

[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]

[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]

[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]

[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

[PATCH 1/1] Add efi e820 memory mapping on x86 [try #1]

[Edgar Hucek]

This Patch add an efi e820 memory mapping.

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


diff -uNr linux-2.6.18-rc2/arch/i386/kernel/setup.c
linux-2.6.18-rc2.mactel/arch/i386/kernel/setup.c
--- linux-2.6.18-rc2/arch/i386/kernel/setup.c    2006-07-16
10:38:10.000000000 +0200
+++ linux-2.6.18-rc2.mactel/arch/i386/kernel/setup.c    2006-07-16
10:16:12.000000000 +0200
@@ -414,19 +414,17 @@
 {
     int x;
 
-    if (!efi_enabled) {
-               x = e820.nr_map;
+    x = e820.nr_map;
 
-        if (x == E820MAX) {
-            printk(KERN_ERR "Ooops! Too many entries in the memory
map!\n");
-            return;
-        }
-
-        e820.map[x].addr = start;
-        e820.map[x].size = size;
-        e820.map[x].type = type;
-        e820.nr_map++;
+    if (x == E820MAX) {
+        printk(KERN_ERR "Ooops! Too many entries in the memory map!\n");
+        return;
     }
+
+    e820.map[x].addr = start;
+    e820.map[x].size = size;
+    e820.map[x].type = type;
+    e820.nr_map++;
 } /* add_memory_region */
 
 #define E820_DEBUG    1
@@ -1431,6 +1429,59 @@
 #endif
 
 /*
+ * Make a e820 memory map
+ */
+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_RUNTIME_SERVICES_CODE:
+        case EFI_RUNTIME_SERVICES_DATA:
+        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_LOADER_CODE:
+        case EFI_LOADER_DATA:
+        case EFI_BOOT_SERVICES_CODE:
+        case EFI_BOOT_SERVICES_DATA:
+        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;
+        }
+    }
+}
+
+/*
  * Determine if we were loaded by an EFI loader.  If so, then we have
also been
  * passed the efi memmap, systab, etc., so we should use these data
structures
  * for initialization.  Note, the efi init code path is determined by the
@@ -1478,9 +1529,11 @@
     rd_doload = ((RAMDISK_FLAGS & RAMDISK_LOAD_FLAG) != 0);
 #endif
     ARCH_SETUP
-    if (efi_enabled)
+    if (efi_enabled) {
         efi_init();
-    else {
+        efi_init_e820_map();
+        print_memory_map("BIOS-EFI");
+    } else {
         printk(KERN_INFO "BIOS-provided physical RAM map:\n");
         print_memory_map(machine_specific_memory_setup());
     }

Re: [PATCH 1/1] Add efi e820 memory mapping on x86 [try #1]

[Andrew Morton]

On Sun, 16 Jul 2006 10:55:30 +0200
Edgar Hucek <hostmaster@ed-soft.at> wrote:

> This Patch add an efi e820 memory mapping.
> 

Why?

>  /*
> + * Make a e820 memory map
> + */
> +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;

I guess these should have type resource_size_t, given that they ultimately
get remembered via request_resource().  But that has a good chance of
breaking something, so let's leave it alone.

> +            add_memory_region(md->phys_addr, md->num_pages <<
> EFI_PAGE_SHIFT, E820_ACPI);

The patch is wordwrapped and will not apply.

Re: [PATCH 1/1] Add efi e820 memory mapping on x86 [try #1]

[Eric W. Biederman]

Andrew Morton <akpm@osdl.org> writes:

> On Sun, 16 Jul 2006 10:55:30 +0200
> Edgar Hucek <hostmaster@ed-soft.at> wrote:
>
>> This Patch add an efi e820 memory mapping.
>> 
>
> Why?

The x86 architecture needs a way to represent the firmware supplied
memory map in a way that later code can query what is in the map.  The
easiest way to do this is simply to convert the efi memory map into
an e820 memory map.

Eric

Re: [PATCH 1/1] Add efi e820 memory mapping on x86 [try #1]

[Linus Torvalds]

On Mon, 24 Jul 2006, Andrew Morton wrote:
> 
> > This Patch add an efi e820 memory mapping.
> > 
> 
> Why?

EFI is this other Intel brain-damage (the first one being ACPI). It's 
totally different from a normal BIOS, and was brought on by ia64, which 
never had a BIOS, of course. 

Sadly, Apple bought into the whole "BIOS bad, EFI good" hype, so we now 
have x86 machines with EFI as the native boot protocol.

The original EFI code in the kernel basically duplicates all the BIOS 
interfaces (ie everything that looks at a memory map comes in two 
varieties: the normal and tested BIOS e820 variety, and the usually broken 
and hacked-up EFI memory map variety).

Translating the EFI memory map to e820 is very much the sane thing to do, 
and should have been done by ia64 in the first place. Sadly, EFI people 
(a) think that their stinking mess is better than a BIOS and (b) are 
historically ia64-only, so they didn't do that, but went the "we'll just 
duplicate everything using our inferior EFI interfaces" way.

Edgars patch looks fine per se, I'd just wish we had more testers (or, 
alternatively, people would just use bootcamp and make their Apple 
machines look like PC's, but see (a) above).

		Linus

Re: [PATCH 1/1] Add efi e820 memory mapping on x86 [try #1]

[H. Peter Anvin]

Linus Torvalds wrote:
> 
> On Mon, 24 Jul 2006, Andrew Morton wrote:
>>> This Patch add an efi e820 memory mapping.
>>>
>> Why?
> 
> EFI is this other Intel brain-damage (the first one being ACPI). It's 
> totally different from a normal BIOS, and was brought on by ia64, which 
> never had a BIOS, of course. 
> 

You're forgetting PXE.

	-hpa

Re: [PATCH 1/1] Add efi e820 memory mapping on x86 [try #1]

[Linus Torvalds]

On Mon, 24 Jul 2006, H. Peter Anvin wrote:
> 
> You're forgetting PXE.

I don't think I'm forgetting it as much as just repressing it. I don't 
think it actually affects the kernel, does it? I assume the only reason 
you care is that it might affect a bootloader?

		Linus

Re: [PATCH 1/1] Add efi e820 memory mapping on x86 [try #1]

[H. Peter Anvin]

Linus Torvalds wrote:
> 
> On Mon, 24 Jul 2006, H. Peter Anvin wrote:
>> You're forgetting PXE.
> 
> I don't think I'm forgetting it as much as just repressing it. I don't 
> think it actually affects the kernel, does it? I assume the only reason 
> you care is that it might affect a bootloader?
> 

Well, one could write an UNDI (PXE) network driver for Linux.  Whether 
or not one would want to is another matter...

It obviously affects the bootloader.

	-hpa

Re: [PATCH 1/1] Add efi e820 memory mapping on x86 [try #1]

[Linus Torvalds]

On Mon, 24 Jul 2006, Linus Torvalds wrote:
> 
> Sadly, Apple bought into the whole "BIOS bad, EFI good" hype, so we now 
> have x86 machines with EFI as the native boot protocol.

Btw, that's not totally new. I think some people played around with EFI on 
x86 even before Apple came around. And don't get me wrong - the problem 
with EFI is that it actually superficially looks much better than the 
BIOS, but in practice it ends up being one of those things where it has 
few real advantages, and often just a lot of extra complexity because of 
the "new and improved" interfaces that were largely defined by a 
committee.

I think a lot of the "new standards" tend to be that way. Trying to solve 
a lot of problems and allow everybody to add their own features, instead 
of just saying that it's better to just standardize the hardware.

For example, instead of ACPI, we could just have had standardized hardware 
(and a few tables to define things like numbers of CPU's etc). It would 
have been simpler for everybody. But no, people seem to think that it's 
somehow "better" to have wild and crazy hardware, and then have a really 
complicated way of describing it - and driving it - dynamically.

So EFI has this cool shell, a loadable driver framework, and other nice 
features. Where "nice" obviously means "much more complex than the simple 
things they designed in the late seventies back when people were stupid 
and just wanted things to work".

Of course, it's somewhat questionable whether people have actually gotten 
smarter or stupider in the last 30 years. It's not enough time for 
evolution to have increased our brain capacity, but it certainly _is_ 
enough time for most people to no longer understand how hardware works any 
more.

Not a good combination, in other words.

Not that I'd ever claim that the BIOS is wonderful either, but at least 
everybody knows that the BIOS is just a bootloader, and doesn't try to 
make it anything else. 

The absolutely biggest advantage of a BIOS is that it's _so_ inconvenient 
and obviously oldfashioned, that you have to be crazy to want to do 
anything serious in it. Real mode, 16-bit code is actually an _advantage_ 
in that sense. People know how to treat it, and don't get any ideas about 
it being some grandiose framework for anything else than "just load the OS 
and get the hell out of there".

			Linus

[PATCH 1/1] Add force of use MMCONFIG [try #1]

[Edgar Hucek]

This Patch add force for mmconfig.
On Intel Macs the efi firmaware gives
a different memory map then ACPI_MCFG
provides. This makes the chack wether
to use mmconfig or not fail.

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

diff -uNr linux-2.6.18-rc2/arch/i386/Kconfig linux-2.6.18-rc2.mactel/arch/i386/Kconfig
--- linux-2.6.18-rc2/arch/i386/Kconfig	2006-07-16 10:38:09.000000000 +0200
+++ linux-2.6.18-rc2.mactel/arch/i386/Kconfig	2006-07-16 10:16:12.000000000 +0200
@@ -1027,6 +1027,7 @@
 	default y
 
 config PCI_MMCONFIG
+	depends on DMI
 	bool
 	depends on PCI && ACPI && (PCI_GOMMCONFIG || PCI_GOANY)
 	default y
diff -uNr linux-2.6.18-rc2/arch/i386/pci/mmconfig.c linux-2.6.18-rc2.mactel/arch/i386/pci/mmconfig.c
--- linux-2.6.18-rc2/arch/i386/pci/mmconfig.c	2006-07-16 10:38:10.000000000 +0200
+++ linux-2.6.18-rc2.mactel/arch/i386/pci/mmconfig.c	2006-07-16 10:18:04.000000000 +0200
@@ -12,6 +12,8 @@
 #include <linux/pci.h>
 #include <linux/init.h>
 #include <linux/acpi.h>
+#include <linux/dmi.h>
+#include <linux/efi.h>
 #include <asm/e820.h>
 #include "pci.h"
 
@@ -187,6 +189,54 @@
 	}
 }
 
+/*
+ * Print system on which MMCONFIG is forced.
+ */
+
+static int pci_mmcfg_force_system(struct dmi_system_id *id)
+{
+	printk(KERN_INFO "PCI: System %s detected. Force MMCONFIG\n",
+		id->ident);
+	
+	return 0;
+}
+
+/*
+ * DMI table of forced MMCONFIG systems.
+ */
+
+static struct dmi_system_id __initdata pci_mmcfg_dmi_system_apple[] = {
+	{ pci_mmcfg_force_system, "iMac4,1", {
+	  DMI_MATCH(DMI_BIOS_VENDOR,"Apple Computer, Inc."),
+	  DMI_MATCH(DMI_BIOS_VERSION,"iMac4,1") }},
+	{ pci_mmcfg_force_system, "MacBookPro1,1", {
+	  DMI_MATCH(DMI_BIOS_VENDOR,"Apple Computer, Inc."),
+	  DMI_MATCH(DMI_BIOS_VERSION,"MacBookPro1,1") }},
+	{ pci_mmcfg_force_system, "MacBook1,1", {
+	  DMI_MATCH(DMI_BIOS_VENDOR,"Apple Computer, Inc."),
+	  DMI_MATCH(DMI_PRODUCT_NAME,"MacBook1,1")}},
+	{ pci_mmcfg_force_system, "Macmini1,1", {
+	  DMI_MATCH(DMI_BIOS_VENDOR,"Apple Computer, Inc."),
+	  DMI_MATCH(DMI_PRODUCT_NAME,"Macmini1,1")}},
+	{},
+};
+
+/*
+ * Check force MMCONFIG.
+ */
+
+int __init pci_mmcfg_force(void)
+{
+	if (efi_enabled) {
+		if (dmi_check_system(pci_mmcfg_dmi_system_apple)) {
+			add_memory_region(pci_mmcfg_config[0].base_address, 
+				pci_mmcfg_config[0].base_address + MMCONFIG_APER_MIN, E820_RESERVED);
+			return 1;
+		}
+	}
+	return 0;
+}
+
 void __init pci_mmcfg_init(void)
 {
 	if ((pci_probe & PCI_PROBE_MMCONF) == 0)
@@ -198,13 +248,15 @@
 	    (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 (!pci_mmcfg_force()) {
+		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");

Re: [PATCH 1/1] Add force of use MMCONFIG [try #1]

[Andrew Morton]

On Sun, 16 Jul 2006 11:00:21 +0200
Edgar Hucek <hostmaster@ed-soft.at> wrote:

> This Patch add force for mmconfig.
> On Intel Macs the efi firmaware gives
> a different memory map then ACPI_MCFG
> provides. This makes the chack wether
> to use mmconfig or not fail.

Why do we want to do this?  Are the ACPI-provided tables incorrect?  If so,
what problems are caused by this?

Re: [PATCH 1/1] Add force of use MMCONFIG [try #1]

[Linus Torvalds]

On Mon, 24 Jul 2006, Andrew Morton wrote:
> 
> Why do we want to do this?  Are the ACPI-provided tables incorrect?  If so,
> what problems are caused by this?

The ACPI-provided tables are apparently correct, but we sanity-check them 
by _also_ requiring that the mmconfig base address is marked "reserved" in 
the e820 tables.

The EFI memory maps apparently don't do that "reserved" marking.

		Linus

Re: [PATCH 1/1] Add force of use MMCONFIG [try #1]

[Andi Kleen]

Linus Torvalds <torvalds@osdl.org> writes:

> On Mon, 24 Jul 2006, Andrew Morton wrote:
> > 
> > Why do we want to do this?  Are the ACPI-provided tables incorrect?  If so,
> > what problems are caused by this?
> 
> The ACPI-provided tables are apparently correct, but we sanity-check them 
> by _also_ requiring that the mmconfig base address is marked "reserved" in 
> the e820 tables.
> 
> The EFI memory maps apparently don't do that "reserved" marking.

We were planning to remove that heuristic anyways because it produced
far too many false positivies. In fact I think Greg has already 
done it. Then that patch should be obsolete.

-Andi