public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
* Query regarding hole in EFI Memory Map
@ 2018-05-14 23:30 Prakhya, Sai Praneeth
  2018-05-15  1:12 ` Bill Paul
  0 siblings, 1 reply; 6+ messages in thread
From: Prakhya, Sai Praneeth @ 2018-05-14 23:30 UTC (permalink / raw)
  To: edk2-devel@lists.01.org; +Cc: Neri, Ricardo

Hi All,

Recently, I have observed that there was a hole in EFI Memory Map passed by firmware to Linux kernel. So, wanted to check with you if this is expected or not.

My Test setup:
I usually boot qemu with OVMF and Linux kernel. I use below command to boot kernel.
"qemu-system-x86_64 -cpu host -hda <live-image> -serial stdio -bios <OVMF.fd> -m 2G -enable-kvm -smp 2"

I have noticed that the EFI Memory Map (printed by kernel) is almost contiguous but with only one hole ranging from 0xA0000 to 0x100000. As far as I know, kernel hasn't modified this EFI Memory Map, so I am assuming that firmware has passed memory map with a hole. I have looked at UEFI spec "GetMemoryMap()" definition, and it says "The map describes all of memory, no matter how it is being used". So, I am thinking that EFI Memory Map shouldn't have any holes, am I correct? If not, could someone please explain me the reason for this hole in EFI Memory Map.



Please let me know if you want me to post the EFI Memory Map or E820 map that I am looking at.

Note: I have also observed the same hole in E820 map.



Regards,

Sai


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Query regarding hole in EFI Memory Map
  2018-05-14 23:30 Query regarding hole in EFI Memory Map Prakhya, Sai Praneeth
@ 2018-05-15  1:12 ` Bill Paul
  2018-05-15  1:18   ` Tim Lewis
  2018-05-15  1:29   ` Prakhya, Sai Praneeth
  0 siblings, 2 replies; 6+ messages in thread
From: Bill Paul @ 2018-05-15  1:12 UTC (permalink / raw)
  To: edk2-devel; +Cc: Prakhya, Sai Praneeth, Neri, Ricardo

Of all the gin joints in all the towns in all the world, Prakhya, Sai Praneeth 
had to walk into mine at 16:30 on Monday 14 May 2018 and say:

> Hi All,
> 
> Recently, I have observed that there was a hole in EFI Memory Map passed by
> firmware to Linux kernel. So, wanted to check with you if this is expected
> or not.
> 
> My Test setup:
> I usually boot qemu with OVMF and Linux kernel. I use below command to boot
> kernel. "qemu-system-x86_64 -cpu host -hda <live-image> -serial stdio
> -bios <OVMF.fd> -m 2G -enable-kvm -smp 2"
> 
> I have noticed that the EFI Memory Map (printed by kernel) is almost
> contiguous but with only one hole ranging from 0xA0000 to 0x100000. As far
> as I know, kernel hasn't modified this EFI Memory Map, so I am assuming
> that firmware has passed memory map with a hole. I have looked at UEFI
> spec "GetMemoryMap()" definition, and it says "The map describes all of
> memory, no matter how it is being used". So, I am thinking that EFI Memory
> Map shouldn't have any holes, am I correct? If not, could someone please
> explain me the reason for this hole in EFI Memory Map.

The map may describe all of physical RAM, however it is not necessarily the 
case that all available RAM be physically contiguous.

With older IBM PCs based on the Intel 8088 processor, you could only have a 
1MB address space. The first 640KB was available for RAM. The remaining space 
traditionally contained memory-mapped option ROMs, particularly for things 
like the video BIOS routines. The VGA text screen was also mapped to 0xB8000.

Obviously, later processors made it possible to have additional memory above 
1MB (sometimes called "high memory"), but for backward compatibility purposes, 
the gap from 0xA0000 to 0xFFFFF remained.

So basically, on Intel machines you will always see this gap in RAM due to 
"hysterical raisins." It's just an artifact of the platform design. (And for 
that reason you'll see it both with the UEFI memory map facility and the 
legacy E820 BIOS facility).

-Bill


> 
> 
> Please let me know if you want me to post the EFI Memory Map or E820 map
> that I am looking at.
> 
> Note: I have also observed the same hole in E820 map.
> 
> 
> 
> Regards,
> 
> Sai
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
-- 
=============================================================================
-Bill Paul            (510) 749-2329 | Senior Member of Technical Staff,
                 wpaul@windriver.com | Master of Unix-Fu - Wind River Systems
=============================================================================
   "I put a dollar in a change machine. Nothing changed." - George Carlin
=============================================================================


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Query regarding hole in EFI Memory Map
  2018-05-15  1:12 ` Bill Paul
@ 2018-05-15  1:18   ` Tim Lewis
  2018-05-15  1:29   ` Prakhya, Sai Praneeth
  1 sibling, 0 replies; 6+ messages in thread
From: Tim Lewis @ 2018-05-15  1:18 UTC (permalink / raw)
  To: 'Bill Paul', edk2-devel; +Cc: 'Neri, Ricardo'

And now you see it again with 64-bit machines, where the flash and PCI
config space (and MMIO) appear below 4GB, but there is DRAM above and below
4GB. 

Tim

-----Original Message-----
From: edk2-devel <edk2-devel-bounces@lists.01.org> On Behalf Of Bill Paul
Sent: Monday, May 14, 2018 6:13 PM
To: edk2-devel@lists.01.org
Cc: Neri, Ricardo <ricardo.neri@intel.com>
Subject: Re: [edk2] Query regarding hole in EFI Memory Map

Of all the gin joints in all the towns in all the world, Prakhya, Sai
Praneeth had to walk into mine at 16:30 on Monday 14 May 2018 and say:

> Hi All,
> 
> Recently, I have observed that there was a hole in EFI Memory Map 
> passed by firmware to Linux kernel. So, wanted to check with you if 
> this is expected or not.
> 
> My Test setup:
> I usually boot qemu with OVMF and Linux kernel. I use below command to 
> boot kernel. "qemu-system-x86_64 -cpu host -hda <live-image> -serial 
> stdio -bios <OVMF.fd> -m 2G -enable-kvm -smp 2"
> 
> I have noticed that the EFI Memory Map (printed by kernel) is almost 
> contiguous but with only one hole ranging from 0xA0000 to 0x100000. As 
> far as I know, kernel hasn't modified this EFI Memory Map, so I am 
> assuming that firmware has passed memory map with a hole. I have 
> looked at UEFI spec "GetMemoryMap()" definition, and it says "The map 
> describes all of memory, no matter how it is being used". So, I am 
> thinking that EFI Memory Map shouldn't have any holes, am I correct? 
> If not, could someone please explain me the reason for this hole in EFI
Memory Map.

The map may describe all of physical RAM, however it is not necessarily the
case that all available RAM be physically contiguous.

With older IBM PCs based on the Intel 8088 processor, you could only have a
1MB address space. The first 640KB was available for RAM. The remaining
space traditionally contained memory-mapped option ROMs, particularly for
things like the video BIOS routines. The VGA text screen was also mapped to
0xB8000.

Obviously, later processors made it possible to have additional memory above
1MB (sometimes called "high memory"), but for backward compatibility
purposes, the gap from 0xA0000 to 0xFFFFF remained.

So basically, on Intel machines you will always see this gap in RAM due to
"hysterical raisins." It's just an artifact of the platform design. (And for
that reason you'll see it both with the UEFI memory map facility and the
legacy E820 BIOS facility).

-Bill


> 
> 
> Please let me know if you want me to post the EFI Memory Map or E820 
> map that I am looking at.
> 
> Note: I have also observed the same hole in E820 map.
> 
> 
> 
> Regards,
> 
> Sai
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
--
============================================================================
=
-Bill Paul            (510) 749-2329 | Senior Member of Technical Staff,
                 wpaul@windriver.com | Master of Unix-Fu - Wind River
Systems
============================================================================
=
   "I put a dollar in a change machine. Nothing changed." - George Carlin
============================================================================
=
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Query regarding hole in EFI Memory Map
  2018-05-15  1:12 ` Bill Paul
  2018-05-15  1:18   ` Tim Lewis
@ 2018-05-15  1:29   ` Prakhya, Sai Praneeth
  2018-05-16  8:07     ` Marvin H?user
  1 sibling, 1 reply; 6+ messages in thread
From: Prakhya, Sai Praneeth @ 2018-05-15  1:29 UTC (permalink / raw)
  To: Bill Paul, edk2-devel@lists.01.org; +Cc: Neri, Ricardo

> Of all the gin joints in all the towns in all the world, Prakhya, Sai Praneeth had to
> walk into mine at 16:30 on Monday 14 May 2018 and say:
> 
> > Hi All,
> >
> > Recently, I have observed that there was a hole in EFI Memory Map
> > passed by firmware to Linux kernel. So, wanted to check with you if
> > this is expected or not.
> >
> > My Test setup:
> > I usually boot qemu with OVMF and Linux kernel. I use below command to
> > boot kernel. "qemu-system-x86_64 -cpu host -hda <live-image> -serial
> > stdio -bios <OVMF.fd> -m 2G -enable-kvm -smp 2"
> >
> > I have noticed that the EFI Memory Map (printed by kernel) is almost
> > contiguous but with only one hole ranging from 0xA0000 to 0x100000. As
> > far as I know, kernel hasn't modified this EFI Memory Map, so I am
> > assuming that firmware has passed memory map with a hole. I have
> > looked at UEFI spec "GetMemoryMap()" definition, and it says "The map
> > describes all of memory, no matter how it is being used". So, I am
> > thinking that EFI Memory Map shouldn't have any holes, am I correct?
> > If not, could someone please explain me the reason for this hole in EFI
> Memory Map.
> 
> The map may describe all of physical RAM, however it is not necessarily the case
> that all available RAM be physically contiguous.
> 
> With older IBM PCs based on the Intel 8088 processor, you could only have a
> 1MB address space. The first 640KB was available for RAM. The remaining space
> traditionally contained memory-mapped option ROMs, particularly for things
> like the video BIOS routines. The VGA text screen was also mapped to 0xB8000.
> 
> Obviously, later processors made it possible to have additional memory above
> 1MB (sometimes called "high memory"), but for backward compatibility
> purposes, the gap from 0xA0000 to 0xFFFFF remained.
> 
> So basically, on Intel machines you will always see this gap in RAM due to
> "hysterical raisins." It's just an artifact of the platform design. (And for that
> reason you'll see it both with the UEFI memory map facility and the legacy E820
> BIOS facility).

Thanks a lot! for the explanation Bill. I really appreciate it :)

Regards,
Sai


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Query regarding hole in EFI Memory Map
  2018-05-15  1:29   ` Prakhya, Sai Praneeth
@ 2018-05-16  8:07     ` Marvin H?user
  2018-05-17 23:36       ` Prakhya, Sai Praneeth
  0 siblings, 1 reply; 6+ messages in thread
From: Marvin H?user @ 2018-05-16  8:07 UTC (permalink / raw)
  To: edk2-devel@lists.01.org
  Cc: Prakhya, Sai Praneeth, wpaul@windriver.com,
	ricardo.neri@intel.com

Hey Sai and others,

I did not verify this is actually the case for QEMU, but the mentioned range is usually the SMRAM ASEG.
SMRAM ranges are not reported in the Memory Map by-design.

Regards,
Marvin

> -----Original Message-----
> From: edk2-devel <edk2-devel-bounces@lists.01.org> On Behalf Of Prakhya,
> Sai Praneeth
> Sent: Tuesday, May 15, 2018 3:29 AM
> To: Bill Paul <wpaul@windriver.com>; edk2-devel@lists.01.org
> Cc: Neri, Ricardo <ricardo.neri@intel.com>
> Subject: Re: [edk2] Query regarding hole in EFI Memory Map
> 
> > Of all the gin joints in all the towns in all the world, Prakhya, Sai
> > Praneeth had to walk into mine at 16:30 on Monday 14 May 2018 and say:
> >
> > > Hi All,
> > >
> > > Recently, I have observed that there was a hole in EFI Memory Map
> > > passed by firmware to Linux kernel. So, wanted to check with you if
> > > this is expected or not.
> > >
> > > My Test setup:
> > > I usually boot qemu with OVMF and Linux kernel. I use below command
> > > to boot kernel. "qemu-system-x86_64 -cpu host -hda <live-image>
> > > -serial stdio -bios <OVMF.fd> -m 2G -enable-kvm -smp 2"
> > >
> > > I have noticed that the EFI Memory Map (printed by kernel) is almost
> > > contiguous but with only one hole ranging from 0xA0000 to 0x100000.
> > > As far as I know, kernel hasn't modified this EFI Memory Map, so I
> > > am assuming that firmware has passed memory map with a hole. I have
> > > looked at UEFI spec "GetMemoryMap()" definition, and it says "The
> > > map describes all of memory, no matter how it is being used". So, I
> > > am thinking that EFI Memory Map shouldn't have any holes, am I correct?
> > > If not, could someone please explain me the reason for this hole in
> > > EFI
> > Memory Map.
> >
> > The map may describe all of physical RAM, however it is not
> > necessarily the case that all available RAM be physically contiguous.
> >
> > With older IBM PCs based on the Intel 8088 processor, you could only
> > have a 1MB address space. The first 640KB was available for RAM. The
> > remaining space traditionally contained memory-mapped option ROMs,
> > particularly for things like the video BIOS routines. The VGA text screen was
> also mapped to 0xB8000.
> >
> > Obviously, later processors made it possible to have additional memory
> > above 1MB (sometimes called "high memory"), but for backward
> > compatibility purposes, the gap from 0xA0000 to 0xFFFFF remained.
> >
> > So basically, on Intel machines you will always see this gap in RAM
> > due to "hysterical raisins." It's just an artifact of the platform
> > design. (And for that reason you'll see it both with the UEFI memory
> > map facility and the legacy E820 BIOS facility).
> 
> Thanks a lot! for the explanation Bill. I really appreciate it :)
> 
> Regards,
> Sai
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Query regarding hole in EFI Memory Map
  2018-05-16  8:07     ` Marvin H?user
@ 2018-05-17 23:36       ` Prakhya, Sai Praneeth
  0 siblings, 0 replies; 6+ messages in thread
From: Prakhya, Sai Praneeth @ 2018-05-17 23:36 UTC (permalink / raw)
  To: Marvin H?user, edk2-devel@lists.01.org; +Cc: wpaul@windriver.com, Neri, Ricardo

> Hey Sai and others,
> 
> I did not verify this is actually the case for QEMU, but the mentioned range is
> usually the SMRAM ASEG.
> SMRAM ranges are not reported in the Memory Map by-design.
> 

Thanks for educating us on this Marvin :)

Regards,
Sai


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2018-05-17 23:36 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-05-14 23:30 Query regarding hole in EFI Memory Map Prakhya, Sai Praneeth
2018-05-15  1:12 ` Bill Paul
2018-05-15  1:18   ` Tim Lewis
2018-05-15  1:29   ` Prakhya, Sai Praneeth
2018-05-16  8:07     ` Marvin H?user
2018-05-17 23:36       ` Prakhya, Sai Praneeth

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox