Hi Andreas,
Segmented controllers works on x86 system now. I can boot Linux with 147GB
memory. i have three controllers as:
self.physmem1 = SimpleDDR3(range = AddrRange(start='0MB',size='3GB'))
self.physmem2 = SimpleDDR3(range = AddrRange(start='8GB',size='128GB'))
self.physmem3 = SimpleDDR3(range =
AddrRange(start='196GB',size='16GB'))
For above, e820 table should be:
self.e820_table.entries = \
[
X86E820Entry(addr = 0, size = '639kB', range_type = 1),
X86E820Entry(addr = 0x9fc00, size = '385kB', range_type = 2),
X86E820Entry(addr = 0x100000, size = '%dB' % (0xc0000000 -
0x100000), range_type = 1),
X86E820Entry(addr = 0x200000000, size = '128GB', range_type = 1),
X86E820Entry(addr = 0x3100000000, size = '16GB', range_type = 1)
]
Please can you tell me when the Linux on gem5 would go on swapping with
above configuration? Would that be when RAM on actual physical hardware
will run out? My physical system has 4GB RAM.
Second, what abstract_mem.c:access is doing. Where does these memcpy
operations copying data? Do they affect the latency/timing/power number of
a memory controller?
Thanks.
Best Regards, Hassan
On 3 December 2013 16:58, Ahmad Hassan <[email protected]> wrote:
> Hi Andreas,
>
> Thanks for the help. I think I figured out the cause of this problem. In
> x86 system, e820 table tells the system which physical addresses are
> available in the hardware. So I need to define proper entries in e826
> dictionary inside FSConfig.py based on the defined memory controller
> ranges. If I define three memory controller and configure their ranges in
> e820, I get the following error. Please can someone expert in configuring
> e820 table guide me how to fix this mapping issue? Thanks
>
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
> BIOS-e820: 000000000009fc00 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 0000000010000000 (usable)
> BIOS-e820: 0000000280000000 - 00000002c0000000 (usable)
> BIOS-e820: 0000003100000000 - 0000003140000000 (usable)
> end_pfn_map = 51642368
> kernel direct mapping tables up to 3140000000 @ 100000-1c6000
> DMI 2.5 present.
> Zone PFN ranges:
> DMA 0 -> 4096
> DMA32 4096 -> 1048576
> Normal 1048576 -> 51642368
> early_node_map[4] active PFN ranges
> 0: 0 -> 159
> 0: 256 -> 65536
> 0: 2621440 -> 2883584
> 0: 51380224 -> 51642368
> bootmem alloc of 2891972608 bytes failed!
> Kernel panic - not syncing: Out of memory
> PANIC: early exception rip ffffffff80215ca0 error 0 cr2 ffffffffff5fd030
>
> Best Regards, Hassan
>
>
>
>
> On 2 December 2013 17:37, Andreas Hansson <[email protected]> wrote:
>
>> Hi Hassan,
>>
>> Someone skilled in the assumptions of x86 memory layout may be able to
>> help you. I doubt there is an easy fix, but I could be wrong.
>>
>> For ARM it should not be a problem to have this “segmented” memory.
>> Currently the gem5 ARM Linux System assumes a single range presented to the
>> OS, but this could easily be fixed (see LinuxArmSystem::initState). If you
>> take the plunge and go this route please share the patch on RB.
>>
>> Thanks,
>>
>> Andreas
>>
>> From: Ahmad Hassan <[email protected]>
>> Reply-To: gem5 users mailing list <[email protected]>
>> Date: Monday, 2 December 2013 16:18
>>
>> To: gem5 users mailing list <[email protected]>
>> Subject: Re: [gem5-users] Running two SimpleDram instances
>> simulataniously
>>
>> Hi Andreas,
>>
>> Please may I ask if you are experiencing the similar errors if you
>> define a second main memory controller beyond IO physical address ranges?
>> Would this be happening or this is completely an undesired behavior?
>>
>> If Linux always need contiguous physical address range for multiple
>> memory controllers then is it possible to move IO address range from 3GB
>> start address to something 128GB starting address and then define two main
>> memory controllers that share the physical address range of 0GB to 128GB to
>> have 128 GB RAM capacity please?
>>
>> In another attempt, I tried to move the first main memory controller
>> starting from 0GB to 10GB but it doesn't work because linux is accessing
>> memory between 0 to 128MB address range.
>>
>> Thanks again for your help.
>>
>> Best Regards, Hassan
>>
>>
>>
>>
>> On 28 November 2013 15:55, Ahmad Hassan <[email protected]> wrote:
>>
>>> Hi Andreas,
>>>
>>> To make sure it is not caused by my local changes, I just cloned the
>>> fresh revison 9644:07352f119e48 and defined two memory controllers as:
>>>
>>> self.physmem = SimpleDDR3(range = AddrRange(start="0GB",
>>> size="2GB"))
>>> self.physmem2 = SimpleDDR3(range =
>>> AddrRange(start="50GB",size="1GB"))
>>> self.mem_ranges = [self.physmem.range,self.physmem2.range]
>>>
>>> Again, I see the same error where linux boot-up fails while accessing
>>> physical address: 3217031168. It seems that guest OS assumes that All 3GB
>>> space is contiguous.
>>>
>>> I don't know why it worked last week.
>>>
>>> Thanks for the help.
>>>
>>> Best Regards, Hassan
>>>
>>>
>>>
>>>
>>> On 28 November 2013 14:50, Ahmad Hassan <[email protected]> wrote:
>>>
>>>> Hi Andreas,
>>>>
>>>> I assume so. I get this 'segmentation fault' while booting
>>>> linux: ./build/X86/gem5.opt configs/example/fs.py
>>>> --kernel=x86_64-vmlinux-2.6.22.9.smp
>>>>
>>>> But I think, I booted the linux last week with similar configuration
>>>> and I think it worked fine. It seems bit strange to me that I am seeing
>>>> this segmentation fault now.
>>>>
>>>> Best Regards, Hassan
>>>>
>>>>
>>>> On 28 November 2013 13:53, Andreas Hansson <[email protected]>wrote:
>>>>
>>>>> Hi Hassan,
>>>>>
>>>>> What is it that is assuming that the memory is contiguous? The guest
>>>>> OS?
>>>>>
>>>>> Andreas
>>>>>
>>>>> From: Ahmad Hassan <[email protected]>
>>>>> Reply-To: gem5 users mailing list <[email protected]>
>>>>> Date: Thursday, 28 November 2013 06:43
>>>>>
>>>>> To: gem5 users mailing list <[email protected]>
>>>>> Subject: Re: [gem5-users] Running two SimpleDram instances
>>>>> simulataniously
>>>>>
>>>>> Hi Andreas,
>>>>>
>>>>> I have defined two memory controllers:
>>>>>
>>>>> self.dram2_ctl = SimpleDDR3(range =
>>>>> AddrRange(start='0MB',size='3GB'))
>>>>> self.dram1_ctl = SimpleDDR3(range =
>>>>> AddrRange(start='10GB',size='16GB'))
>>>>>
>>>>> But I am getting exception in findPort method where it raises
>>>>> because it tries to access physical address 6438256672 for membus
>>>>>
>>>>> DPRINTF(BusAddrRanges, "Unable to find destination for addr %#llx, "
>>>>> "will use default port\n", addr);
>>>>>
>>>>> As a result of that, I get segmentation fault during memcpy
>>>>> operation in abstract_mem.cc:access
>>>>> This error is happening because system is assuming that all the 19GB
>>>>> of physical memory is contiguous. Please can you advise me how to fix
>>>>> this.
>>>>> Thanks.
>>>>>
>>>>> Best Regards, Hassan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 31 October 2013 18:00, Andreas Hansson <[email protected]>wrote:
>>>>>
>>>>>> Hi Ahmad,
>>>>>>
>>>>>> If you change the bus code then every bus in the system will do
>>>>>> this, including the I/O bus. I suspect this is the reason for your error.
>>>>>> You can keep on the hackish path and add a name check to only do this for
>>>>>> the membus (or add a parameter to the bus and change the MemBus
>>>>>> instance),
>>>>>> or preferably get of the hackish path and rely on physical addresses and
>>>>>> sort out your “placement” by assigning the appropriate physical addresses
>>>>>> in your TLBs (or preferably in the OS).
>>>>>>
>>>>>> Red pill or blue pill.
>>>>>>
>>>>>> Andreas
>>>>>>
>>>>>> From: Ahmad Hassan <[email protected]>
>>>>>> Reply-To: gem5 users mailing list <[email protected]>
>>>>>> Date: Thursday, 31 October 2013 16:51
>>>>>>
>>>>>> To: gem5 users mailing list <[email protected]>
>>>>>> Subject: Re: [gem5-users] Running two SimpleDram instances
>>>>>> simulataniously
>>>>>>
>>>>>> Hi Andreas,
>>>>>>
>>>>>> In my system:
>>>>>> DDR3 memory controller: Port ID 0 //2GB capacity
>>>>>> DDR2 memory controller: Port ID 1 //1GB capacity
>>>>>>
>>>>>> So I want to do the following:
>>>>>>
>>>>>> When the packet comes into bus.cc:findPort then it searches for
>>>>>> packet's physical address in the registered portMap of address ranges
>>>>>> and
>>>>>> returns the appropriate port ID. I don't want to do this. Instead, I want
>>>>>> to select port based on the virtual address. I have list of virtual
>>>>>> addresses say V=[V1....Vn] and I want to redirect all the packets with
>>>>>> virtual address within set 'V' to DDR3 Port 0 and all other memory
>>>>>> packets
>>>>>> to the DDR2 port 1.
>>>>>>
>>>>>> In order to achieve this, I changed bus.cc:findPort as:
>>>>>>
>>>>>> if (search(V, pkt->req->getVaddr()) == true)
>>>>>> dest_id = 0;
>>>>>> else
>>>>>> dest_id = 1;
>>>>>>
>>>>>> After that, abstract_mem.cc:access complained that the packet
>>>>>> address doesn't belong to the range of PORT '1'. Just as a quick hack, I
>>>>>> changed it as:
>>>>>>
>>>>>> old: uint8_t *hostAddr = pmemAddr + pkt->getAddr() - range.start();
>>>>>> new: uint8_t *hostAddr = pmemAddr + pkt->getAddr() - 0; // Port ID
>>>>>> 0 range starts with '0'
>>>>>>
>>>>>> Now the linux starts booting but during the half way, it throws
>>>>>> this cmos assertion. Please can you suggest the clean or right way of
>>>>>> implementing what I am trying to achieve.
>>>>>>
>>>>>> Thanks a lot
>>>>>>
>>>>>> kind Regards, Ahmad
>>>>>>
>>>>>>
>>>>>> On 31 October 2013 16:25, Andreas Hansson <[email protected]>wrote:
>>>>>>
>>>>>>> Hi Ahmad,
>>>>>>>
>>>>>>> I could be wrong, but judging by your mail, I get the impression
>>>>>>> that you’re overriding the address decoding. That is essentially saying
>>>>>>> “If
>>>>>>> I send requests for address X to address Y, why do things not work?”. I
>>>>>>> would be very surprised if it did, as two addresses will now map to the
>>>>>>> same location :-). Perhaps I’m not understanding what you’ve changed.
>>>>>>>
>>>>>>> Andreas
>>>>>>>
>>>>>>> From: Ahmad Hassan <[email protected]>
>>>>>>> Reply-To: gem5 users mailing list <[email protected]>
>>>>>>> Date: Thursday, 31 October 2013 16:12
>>>>>>>
>>>>>>> To: gem5 users mailing list <[email protected]>
>>>>>>> Subject: Re: [gem5-users] Running two SimpleDram instances
>>>>>>> simulataniously
>>>>>>>
>>>>>>> HI Andreas,
>>>>>>>
>>>>>>> I have connected two memory controllers and I can see the
>>>>>>> following two port IDs and their physical address ranges:
>>>>>>>
>>>>>>> Adding range [0 : 2147483647] for id 0 system.membus // 2GB
>>>>>>> memory
>>>>>>> Adding range [2147483648 : 3221225471] for id 1 system.membus
>>>>>>> //1GB memroy
>>>>>>>
>>>>>>> Inside findPort method of bus.cc, if I assign the packet of port
>>>>>>> id '0' to port id '1' then I get the following assertion error. This
>>>>>>> happens in half way through the linux boot up:
>>>>>>>
>>>>>>> gem5.opt: build/X86/dev/x86/cmos.cc:70: virtual Tick
>>>>>>> X86ISA::Cmos::write(PacketPtr): Assertion `pkt->getSize() == 1' failed.
>>>>>>>
>>>>>>> Please do you know what is causing that? Also I had to disable
>>>>>>> assertion in abstract memory which validates that the packet's physical
>>>>>>> address in with in the range of memory controller.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> kind Regards, Ahmad
>>>>>>>
>>>>>>> -- IMPORTANT NOTICE: The contents of this email and any attachments
>>>>>>> are confidential and may also be privileged. If you are not the intended
>>>>>>> recipient, please notify the sender immediately and do not disclose the
>>>>>>> contents to any other person, use it for any purpose, or store or copy
>>>>>>> the
>>>>>>> information in any medium. Thank you.
>>>>>>>
>>>>>>> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
>>>>>>> Registered in England & Wales, Company No: 2557590
>>>>>>> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
>>>>>>> 9NJ, Registered in England & Wales, Company No: 2548782
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> gem5-users mailing list
>>>>>>> [email protected]
>>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>>>
>>>>>>
>>>>>>
>>>>>> -- IMPORTANT NOTICE: The contents of this email and any attachments
>>>>>> are confidential and may also be privileged. If you are not the intended
>>>>>> recipient, please notify the sender immediately and do not disclose the
>>>>>> contents to any other person, use it for any purpose, or store or copy
>>>>>> the
>>>>>> information in any medium. Thank you.
>>>>>>
>>>>>> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
>>>>>> Registered in England & Wales, Company No: 2557590
>>>>>> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
>>>>>> 9NJ, Registered in England & Wales, Company No: 2548782
>>>>>>
>>>>>> _______________________________________________
>>>>>> gem5-users mailing list
>>>>>> [email protected]
>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>>
>>>>>
>>>>>
>>>>> -- IMPORTANT NOTICE: The contents of this email and any attachments
>>>>> are confidential and may also be privileged. If you are not the intended
>>>>> recipient, please notify the sender immediately and do not disclose the
>>>>> contents to any other person, use it for any purpose, or store or copy the
>>>>> information in any medium. Thank you.
>>>>>
>>>>> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
>>>>> Registered in England & Wales, Company No: 2557590
>>>>> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
>>>>> 9NJ, Registered in England & Wales, Company No: 2548782
>>>>>
>>>>> _______________________________________________
>>>>> gem5-users mailing list
>>>>> [email protected]
>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>>>
>>>>
>>>>
>>>
>>
>> -- IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy the
>> information in any medium. Thank you.
>>
>> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
>> Registered in England & Wales, Company No: 2557590
>> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
>> Registered in England & Wales, Company No: 2548782
>>
>> _______________________________________________
>> gem5-users mailing list
>> [email protected]
>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>
>
>
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
