[SOLVED] QEMU's Memory Detection

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
nbdd0121
Member
Member
Posts: 60
Joined: Thu Jul 25, 2013 8:10 am

[SOLVED] QEMU's Memory Detection

Post by nbdd0121 »

When my tiny "Norlit OS" ran on QEMU, I found that QEMU don't have a ACPI memory area. (However, RSD PTR exists)
Is that OK in ACPI specification?

Image
Last edited by nbdd0121 on Wed Aug 28, 2013 7:26 am, edited 2 times in total.
Top
User avatar
xenos
Member
Member
Posts: 1121
Joined: Thu Aug 11, 2005 11:00 pm
Libera.chat IRC: xenos1984
Location: Tartu, Estonia
Contact:
Contact xenos

Re: QEMU's Memory Detection

Post by xenos »

Where does the RSD PTR point to? I would guess that the ACPI area starts at 0x07FFE000. This is also what my Kernel finds:

Code: Select all

Memory map of length 0x00000090 at address 0x000100c0
Mem: 0x0000000000000000-0x000000000009fbff, Type: 0x01
Mem: 0x000000000009fc00-0x000000000009ffff, Type: 0x02
Mem: 0x00000000000f0000-0x00000000000fffff, Type: 0x02
Mem: 0x0000000000100000-0x0000000003ffdfff, Type: 0x01
Mem: 0x0000000003ffe000-0x0000000003ffffff, Type: 0x02
Mem: 0x00000000fffc0000-0x00000000ffffffff, Type: 0x02

Code: Select all

ACPI RSD pointer:	Rev. 0 found at 0x000fd9a0
ACPI RSDT:	found at 0x03ffe4b0
ACPI RSDT:	OEMID: BOCHS , OEM Table ID: BXPCRSDT, OEM Rev.: 1
ACPI RSDT:	Creator ID: BXPC, Creator Rev.: 1
ACPI FACP:	found at 0x03ffff80
Yes, it's QEMU - it uses the Bochs BIOS, that's why the ACPI identifies itself as Bochs. You should find the same in QEMU if you follow the RSD PTR.
Programmers' Hardware Database // GitHub user: xenos1984; OS project: NOS
Top
User avatar
Love4Boobies
Member
Member
Posts: 2111
Joined: Fri Mar 07, 2008 5:36 pm
Location: Bucharest, Romania

Re: QEMU's Memory Detection

Post by Love4Boobies »

XenOS wrote:Yes, it's QEMU - it uses the Bochs BIOS, that's why the ACPI identifies itself as Bochs. You should find the same in QEMU if you follow the RSD PTR.
Sounds like you have a version of QEMU that is at least 4 years old. The current one is 1.6.0.
"Computers in the future may weigh no more than 1.5 tons.", Popular Mechanics (1949)
[ Project UDI ]
Top
User avatar
xenos
Member
Member
Posts: 1121
Joined: Thu Aug 11, 2005 11:00 pm
Libera.chat IRC: xenos1984
Location: Tartu, Estonia
Contact:
Contact xenos

Re: QEMU's Memory Detection

Post by xenos »

Love4Boobies wrote:Sounds like you have a version of QEMU that is at least 4 years old. The current one is 1.6.0.
Actually I compiled it just a few months ago...

Code: Select all

QEMU emulator version 1.5.0, Copyright (c) 2003-2008 Fabrice Bellard
But now that I know that 1.6.0 is out there, I'll update it ;)

EDIT: Just updated to QEMU 1.6.0, still looks quite similar:

Code: Select all

Memory map of length 0x00000090 at address 0x000100c0
Mem: 0x0000000000000000-0x000000000009fbff, Type: 0x01
Mem: 0x000000000009fc00-0x000000000009ffff, Type: 0x02
Mem: 0x00000000000f0000-0x00000000000fffff, Type: 0x02
Mem: 0x0000000000100000-0x0000000003ffdfff, Type: 0x01
Mem: 0x0000000003ffe000-0x0000000003ffffff, Type: 0x02
Mem: 0x00000000fffc0000-0x00000000ffffffff, Type: 0x02

Code: Select all

ACPI RSD pointer:	not found in range 0x0009fc00 to 0x000a0000
ACPI RSD pointer:	Rev. 0 found at 0x000f16f0
ACPI RSDT:	found at 0x03ffe450
ACPI RSDT:	OEMID: BOCHS , OEM Table ID: BXPCRSDT, OEM Rev.: 1
ACPI RSDT:	Creator ID: BXPC, Creator Rev.: 1
ACPI FACP:	found at 0x03ffff80

Code: Select all

QEMU emulator version 1.6.0, Copyright (c) 2003-2008 Fabrice Bellard
Love4Boobies, what does the ACPI info from your QEMU version look like?
Programmers' Hardware Database // GitHub user: xenos1984; OS project: NOS
Top
User avatar
Love4Boobies
Member
Member
Posts: 2111
Joined: Fri Mar 07, 2008 5:36 pm
Location: Bucharest, Romania

Re: QEMU's Memory Detection

Post by Love4Boobies »

I don't have QEMU installed since I've more or less lost interest in OS development. Sorry for making assumptions---shame on me.
"Computers in the future may weigh no more than 1.5 tons.", Popular Mechanics (1949)
[ Project UDI ]
Top
nbdd0121
Member
Member
Posts: 60
Joined: Thu Jul 25, 2013 8:10 am

Re: QEMU's Memory Detection

Post by nbdd0121 »

XenOS wrote:
Love4Boobies wrote:Sounds like you have a version of QEMU that is at least 4 years old. The current one is 1.6.0.
Actually I compiled it just a few months ago...

Code: Select all

QEMU emulator version 1.5.0, Copyright (c) 2003-2008 Fabrice Bellard
But now that I know that 1.6.0 is out there, I'll update it ;)

EDIT: Just updated to QEMU 1.6.0, still looks quite similar:

Code: Select all

Memory map of length 0x00000090 at address 0x000100c0
Mem: 0x0000000000000000-0x000000000009fbff, Type: 0x01
Mem: 0x000000000009fc00-0x000000000009ffff, Type: 0x02
Mem: 0x00000000000f0000-0x00000000000fffff, Type: 0x02
Mem: 0x0000000000100000-0x0000000003ffdfff, Type: 0x01
Mem: 0x0000000003ffe000-0x0000000003ffffff, Type: 0x02
Mem: 0x00000000fffc0000-0x00000000ffffffff, Type: 0x02

Code: Select all

ACPI RSD pointer:	not found in range 0x0009fc00 to 0x000a0000
ACPI RSD pointer:	Rev. 0 found at 0x000f16f0
ACPI RSDT:	found at 0x03ffe450
ACPI RSDT:	OEMID: BOCHS , OEM Table ID: BXPCRSDT, OEM Rev.: 1
ACPI RSDT:	Creator ID: BXPC, Creator Rev.: 1
ACPI FACP:	found at 0x03ffff80

Code: Select all

QEMU emulator version 1.6.0, Copyright (c) 2003-2008 Fabrice Bellard
Love4Boobies, what does the ACPI info from your QEMU version look like?
But the ACPI Reclaim Memoru should have a type of 3, isn't it?
Top
User avatar
xenos
Member
Member
Posts: 1121
Joined: Thu Aug 11, 2005 11:00 pm
Libera.chat IRC: xenos1984
Location: Tartu, Estonia
Contact:
Contact xenos

Re: QEMU's Memory Detection

Post by xenos »

nbdd0121 wrote:But the ACPI Reclaim Memoru should have a type of 3, isn't it?
Yes, that would be logical. So either this is a bug in QEMU or the memory contains some other stuff used by the BIOS and should not be used at all. In Bochs it has type 3:

Code: Select all

Memory map of length 0x000000a8 at address 0x000100c0
Mem: 0x0000000000000000-0x000000000009efff, Type: 0x01
Mem: 0x000000000009f000-0x000000000009ffff, Type: 0x02
Mem: 0x00000000000e8000-0x00000000000fffff, Type: 0x02
Mem: 0x0000000000100000-0x00000000bffeffff, Type: 0x01
Mem: 0x00000000bfff0000-0x00000000bfffffff, Type: 0x03
Mem: 0x00000000fffc0000-0x00000000ffffffff, Type: 0x02
Mem: 0x0000000100000000-0x00000001ffffffff, Type: 0x01

Code: Select all

ACPI RSD pointer:	Rev. 0 found at 0x000fa640
ACPI RSDT:	found at 0xbfff0000
ACPI RSDT:	OEMID: BOCHS , OEM Table ID: BXPCRSDT, OEM Rev.: 1
ACPI RSDT:	Creator ID: BXPC, Creator Rev.: 1
ACPI FACP:	found at 0xbfff0030
Programmers' Hardware Database // GitHub user: xenos1984; OS project: NOS
Top
nbdd0121
Member
Member
Posts: 60
Joined: Thu Jul 25, 2013 8:10 am

Re: QEMU's Memory Detection

Post by nbdd0121 »

XenOS wrote: Yes, that would be logical. So either this is a bug in QEMU or the memory contains some other stuff used by the BIOS and should not be used at all. In Bochs it has type 3:
Well, that is the problem. My code relys heavily on the memory map, so my code cannot work on QEMU.
Top
User avatar
xenos
Member
Member
Posts: 1121
Joined: Thu Aug 11, 2005 11:00 pm
Libera.chat IRC: xenos1984
Location: Tartu, Estonia
Contact:
Contact xenos

Re: QEMU's Memory Detection

Post by xenos »

I guess it's not a big loss if you treat those 4kB as not usable instead of reclaiming them. Just make sure you can map and access them when it is necessary (because the RSD PTR points to that area and you are supposed to read ACPI tables from there). You will need to map memory regions of type 2 anyway (such as video RAM, EBDA etc.).
Programmers' Hardware Database // GitHub user: xenos1984; OS project: NOS
Top
nbdd0121
Member
Member
Posts: 60
Joined: Thu Jul 25, 2013 8:10 am

Re: QEMU's Memory Detection

Post by nbdd0121 »

XenOS wrote:I guess it's not a big loss if you treat those 4kB as not usable instead of reclaiming them. Just make sure you can map and access them when it is necessary (because the RSD PTR points to that area and you are supposed to read ACPI tables from there). You will need to map memory regions of type 2 anyway (such as video RAM, EBDA etc.).
Actually I only map until MAX{mem_size, 768MB}. The type 2 will influence the calc in mem_size anyway.
Top
User avatar
Combuster
Member
Member
Posts: 9301
Joined: Wed Oct 18, 2006 3:45 am
Libera.chat IRC: [com]buster
Location: On the balcony, where I can actually keep 1½m distance
Contact:
Contact Combuster

Re: QEMU's Memory Detection

Post by Combuster »

One thing to be aware of, if the BIOS needs certain tables for it's own use, they wouldn't be located in an area marked as reclaimable. Such an area doesn't need to exist.

IIRC the official locations that need to be searched for ACPI structures would be the BIOS, EBDA, and top of memory, and in both cases here it turns out to be the top of memory - so that sorts out, obviously.
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
Top
User avatar
Owen
Member
Member
Posts: 1700
Joined: Fri Jun 13, 2008 3:21 pm
Location: Cambridge, United Kingdom
Contact:
Contact Owen

Re: QEMU's Memory Detection

Post by Owen »

There is no reason to expect that the ACPI tables will, in their entirety, be in the ACPI reclaim area and/or RAM, and if you look across a variety of devices you'll find that bits of them aren't; they can point into ROM, reserved memory, etc.

You need to support arbitrary mappings for devices anyway, so supporting them for ACPI is no big deal...
Top
Post Reply

Return to “OS Development”