[gem5-users] Microcode_ROM Instruction and fetchRomMicroop() Function

[Abdelrahman S. Hussein via gem5-users]

Hello,

I am looking at the AtomicSimpleCPU code in src/cpu/simple for x86 ISA. I
am trying to understand the following code snippet. Whenever this condition
is true for a given PC, it does NOT follow the regular fetch from the
instruction cache and then decode. This results in a macroop called
`Microcode_ROM`, which is not an x86 macroop that has a sequence of uops
(can be seen in the O3 CPU). Example: Instruction is:   Microcode_ROM :
ldst   t0, HS:[t0 + t6 + 0x20] (This is taken from the O3 logs running the
same workload by checking the same PC in the Debug logs).

I am not sure what this macroop is and what the benefit is from the code
below. Does this mean this instruction has no x86 machine instruction
binary? If it has an x86 instruction binary, how to get it?

if (isRomMicroPC(pc_state.microPC())) {

t_info.stayAtPC = false;

curStaticInst = decoder->fetchRomMicroop(

pc_state.microPC(), curMacroStaticInst);

}


Thanks,

--

*Best,Abdelrahman Hussein*
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org

[gem5-users] Re: Spec2017 GCC benchmark crashes in SE mode

[muke101 via gem5-users]

Ah, I was trying to do this from arch/arm/process.cc, but I've found 
sim/Process.py which seems to actually control what the value is (at least when 
using the se.py config).

Turns out Process.py already sets a 64MB stack by default. This suggests GCC 
crashing isn't due to running out of stack after all then as this is likely 
already enough. To be certain I've spun up another run with a stack size of 
1GB, but I still expect it to crash.

Is there anything else I can look into in the meantime to try and fix this? 
I've confirmed the problem wasn't fixed by -fno-strict-aliasing too.

Sent with [Proton Mail](https://proton.me/) secure email.

On Wednesday, 17 January 2024 at 02:50, sun2k23 via gem5-users 
 wrote:

> you may have below python coding in your *.py configuration file:
> process = Process(...)
> process.executable = ...
>
> If you want to update the stack base, just add configuration like below:
> process.stackBase = 0x // new stack base value
> process.maxStackSize = 0x // stack size
>
> You can have a try, hope it helps.
>
> S2K
>
> At 2024-01-17 01:22:30, "muke101 via gem5-users"  wrote:
>
>> I see, thanks for the explanation.
>>
>> Could you elaborate for me how I should change the stack base address to 
>> increase available size? I had thought setting a higher address would but 
>> GCC immediately crashes if I do this. If I set a lower address it works but 
>> does this provide more space?
>>
>> Also, is the mmap_end variable relevant at all?
>>
>> Sent from Proton Mail mobile
>>
>>  Original Message 
>> On 16 Jan 2024, 06:07, sun2k23 wrote:
>>
>>> Hi,
>>>
>>> Usually in SE mode, the page would be pre-allocated when the ELF 
>>> file(what's also called image download by me previously) is 
>>> initiated/downloaded to the memory. The allocated page can be checked when 
>>> enabling MMU debug-flag.
>>>
>>> I would suggest you to check the error address to confirm whether the 
>>> related page is allocated, and probably not, then you would check whether 
>>> the error address is located inside stack location or somewhere else. if 
>>> it's outside stack and is an invalid location, maybe you should further 
>>> enlarge the stack space. except for the process.StackSize, i think maybe 
>>> you should also modify the process.stackBase.
>>>
>>> Please let me know if you fix this issue.
>>>
>>> Regards,
>>> S2K.
>>>
>>> At 2024-01-15 09:25:02, "muke101 via gem5-users"  
>>> wrote:
>>>
 Hi, thanks for the reply.

 Assuming that the page isn't being allocated when it should be, what could 
 I do with this information? I'm not familiar with this part of the Gem5 
 codebase.

 Also, just to be clear, what do you mean by 'when the image download is 
 done'?

 Thanks.

 Sent from Proton Mail mobile

  Original Message 
 On 15 Jan 2024, 01:18, sun2k23 via gem5-users wrote:

> Hi,
>
> I have ever met several similar issues but i'm not running Spec2017. I 
> think that's because you use this address 0x66195c before allocating 
> page firstly. You can enable the debug-flag of MMU to check whether the 
> page related to this address is allocated when the image download is done.
>
> S2k
>
> At 2024-01-14 04:40:13, "muke101 via gem5-users"  
> wrote:
>
>> Hi, I'm trying to checkpoint spec2017 with NonCachingSimpleCPU according 
>> to simpoints I generated from native AArch64 binaries. On an unmodified 
>> Gem5, a page fault occurs in the simulation (pasted the error message at 
>> the bottom).
>>
>> I've read that GCC can run out of stack space when simulated, so I 
>> edited arch/arm/process.cc to have a max stack size of 16MB instead of 
>> the default 8MB, but this hasn't helped. Can someone confirm this is the 
>> right way to increase the max stack size? The total memory allowed to 
>> the simulation if 50GB (set if --mem-size on the command line).
>>
>> Another possibility is that it's due to me compiling the benchmark 
>> without '--no-strict-aliasing', which the spec documentation suggests 
>> to, but I imagine if this were the problem then the program wouldn't had 
>> been able to run natively, which it does.
>>
>> Has anyone run into this problem before and been able to solve it?
>>
>> Thanks.
>>
>> build/ARM/sim/simulate.cc:194: info: Entering event queue @ 
>> 188431954680500. Starting simulation...
>> build/ARM/sim/faults.cc:104: panic: panic condition !handled && 
>> !tc->getSystemPtr()->trapToGdb(SIGSEGV, tc->contextId()) occurred: Page 
>> table fault when accessing virtual address 0x66195c
>> Memory Usage: 52735052 KBytes
>> Program aborted at tick 191641021589000
>> --- BEGIN LIBC BACKTRACE ---
>> /sim_home/luke/PND-Loads/gem5/build/ARM/gem5.fast(+0x97d088)[0xca97c088]
>> 

[gem5-users] Using the externalize function of the page table from the cpu

[o.ecemis via gem5-users]

 

Hi, 

I am trying to access all entries of the page table in every tick inside
the cpu. Currently I am trying to access the page tabe externalize()
function by first accessing the thread context of a cpu core, then
getting the process pointer which holds a page table object. 

All process pointers I access using the thread contexts are null
pointers. Is there another way I can access the page table? 

I am using the x86-parsec-benchmarks configuration, but I have changed
the switch_core_type from Timing to O3. 
 ___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org

[gem5-users] x86KvmCPU doesn't work in SE mode?

[wanli990802--- via gem5-users]

CPU : Intel

OS: ubuntu-22

gem5: gem5-v23

After I pass the tutorial of **SETTING UP AND USING KVM ON YOUR MACHINE** and 
that is to say that kvmCPU works in FS mode!\
\
But when I try to run an multithreaded program with openmp in se mode using 
KVMCPU, it throw an error like this:

> src/cpu/kvm/base.cc:1062: panic: KVM: Unexpected exit (exit_reason: 8)

Additionally, When I change the workload to the simplest hello program, it 
throw the same error!

Does anyone konw this issue?
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org

[gem5-users] gem5 Fault Injector tool?

[elio.vinciguerra--- via gem5-users]

Hello everyone, 

I am looking for a valid and working Fault Injector for gem5 with RISCV ISA for 
Full System simulation, which supports transient and permanent faults. 
Regarding the type of faults I have no stringent constraints, for sure I need 
software level faults (register faults, memory etc), but if possible it would 
be useful to have hardware faults as well.

Does anyone know of a Fault Injector that might be right for me?

Regards,

Elio
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org