Re: [gem5-dev] Syscall_Emulation for Shared Memory
Hi Maryam,
You need to tell the simulator how many thread contexts it needs at the
beginning of execution. There's no thread scheduler in SE mode like there'd be
in a real operating system. Since clone allows you to dynamically create a lot
of processes, they need to be bound to thread contexts. Since the simulator
doesn't know how many the application needs you need to tell it.
Pass in the -n option to the configs/example/se.py script. You could try
something like -n4 or w/e.
Regards,
Brandon
-Original Message-
From: gem5-dev On Behalf Of Maryam Babaie
Sent: Monday, March 18, 2019 1:56 PM
To: gem5 Developer List
Subject: Re: [gem5-dev] Syscall_Emulation for Shared Memory
Hi all,
I tried a simple program for testing clone system call on gem5 (SE mode, X86).
Eventhough clone is implemented in the list of system calls, via
cloneFunc; but it works like it's not implemented!
As I checked clone system call always returns in the if clause at
src/sim/syscall_emul.hh:1519 :
if (!(ctc = p->findFreeContext())) {
DPRINTF_SYSCALL(Verbose, "clone: no spare thread context in system"
"[cpu %d, thread %d]", tc->cpuId(), tc->threadId());
return -EAGAIN;
}
Obviously, the reason it returns originates from "ctc =
p->findFreeContext()", in which "findFreeContext()" returns nullptr,
p->but I
cant' figure out why it happens.
I appreciate if any one shares their insight in this regard.
Bests,
MB
On Mon, Mar 11, 2019 at 3:39 PM Potter, Brandon
wrote:
> Hi Maryam,
>
> The code that you are looking at is going to change soon. There is a
> changeset on the google reviewboard which will add some fidelity to
> the tracing of mmap/munmaps from the perspective of SE mode (
> https://gem5-review.googlesource.com/c/public/gem5/+/12307). Feel free
> to review it if it's interesting to you.
>
> 1) I don't understand what you are asking.
> 2) The new patch has an implementation.
> 3) We could probably add an implementation that flushes file-backed
> mmaps to the host file. I have never run into a situation where this
> was needed in an application that was being simulated (so it doesn't
> have an implementation).
> 4) It turns out that fork is not used in Linux to create a new
> process. It uses the clone system call instead. (You can verify this
> by using the Linux strace command with your application. You should
> only see a clone call.) You should take a look at the clone implementation.
>
> Regards,
> Brandon
>
> -Original Message-
> From: gem5-dev On Behalf Of Maryam Babaie
> Sent: Friday, March 8, 2019 4:06 PM
> To: m5-...@m5sim.org
> Subject: [gem5-dev] Syscall_Emulation for Shared Memory
>
> Hi all,
> I have some questions regarding the system calls available in SE mode
> on
> gem5 for X86. I appreciate if any one shares their insight about them:
>
> 1. For the mmap syscall, the function "mmapImpl" has been implemented.
> Up-to which extend this function will work properly for mmap syscall?
>
> 2. For munmap syscall, they have put the munmapFunc, but the body of
> the corresponding function is actually empty. So, does this mean it is
> actually not supported on gem5?
>
> 3. msync syscall is flagged as unimplementedFunc. So, does this mean
> that mmap will still work but the writes will not be reflected
> persistently in the region?
>
> 4. Since the fork syscall is also flagged as unimplementedFunc , how
> is the concept of Copy on Write (generally shared pages) able to be
> simulated and handled in gem5?
>
> Regards
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Syscall_Emulation for Shared Memory
Hi all,
I tried a simple program for testing clone system call on gem5 (SE mode,
X86). Eventhough clone is implemented in the list of system calls, via
cloneFunc; but it works like it's not implemented!
As I checked clone system call always returns in the if clause at
src/sim/syscall_emul.hh:1519 :
if (!(ctc = p->findFreeContext())) {
DPRINTF_SYSCALL(Verbose, "clone: no spare thread context in system"
"[cpu %d, thread %d]", tc->cpuId(), tc->threadId());
return -EAGAIN;
}
Obviously, the reason it returns originates from "ctc =
p->findFreeContext()", in which "findFreeContext()" returns nullptr, but I
cant' figure out why it happens.
I appreciate if any one shares their insight in this regard.
Bests,
MB
On Mon, Mar 11, 2019 at 3:39 PM Potter, Brandon
wrote:
> Hi Maryam,
>
> The code that you are looking at is going to change soon. There is a
> changeset on the google reviewboard which will add some fidelity to the
> tracing of mmap/munmaps from the perspective of SE mode (
> https://gem5-review.googlesource.com/c/public/gem5/+/12307). Feel free to
> review it if it's interesting to you.
>
> 1) I don't understand what you are asking.
> 2) The new patch has an implementation.
> 3) We could probably add an implementation that flushes file-backed mmaps
> to the host file. I have never run into a situation where this was needed
> in an application that was being simulated (so it doesn't have an
> implementation).
> 4) It turns out that fork is not used in Linux to create a new process. It
> uses the clone system call instead. (You can verify this by using the Linux
> strace command with your application. You should only see a clone call.)
> You should take a look at the clone implementation.
>
> Regards,
> Brandon
>
> -Original Message-----
> From: gem5-dev On Behalf Of Maryam Babaie
> Sent: Friday, March 8, 2019 4:06 PM
> To: m5-...@m5sim.org
> Subject: [gem5-dev] Syscall_Emulation for Shared Memory
>
> Hi all,
> I have some questions regarding the system calls available in SE mode on
> gem5 for X86. I appreciate if any one shares their insight about them:
>
> 1. For the mmap syscall, the function "mmapImpl" has been implemented.
> Up-to which extend this function will work properly for mmap syscall?
>
> 2. For munmap syscall, they have put the munmapFunc, but the body of the
> corresponding function is actually empty. So, does this mean it is actually
> not supported on gem5?
>
> 3. msync syscall is flagged as unimplementedFunc. So, does this mean that
> mmap will still work but the writes will not be reflected persistently in
> the region?
>
> 4. Since the fork syscall is also flagged as unimplementedFunc , how is
> the concept of Copy on Write (generally shared pages) able to be simulated
> and handled in gem5?
>
> Regards
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Syscall_Emulation for Shared Memory
Hi Maryam, The code that you are looking at is going to change soon. There is a changeset on the google reviewboard which will add some fidelity to the tracing of mmap/munmaps from the perspective of SE mode (https://gem5-review.googlesource.com/c/public/gem5/+/12307). Feel free to review it if it's interesting to you. 1) I don't understand what you are asking. 2) The new patch has an implementation. 3) We could probably add an implementation that flushes file-backed mmaps to the host file. I have never run into a situation where this was needed in an application that was being simulated (so it doesn't have an implementation). 4) It turns out that fork is not used in Linux to create a new process. It uses the clone system call instead. (You can verify this by using the Linux strace command with your application. You should only see a clone call.) You should take a look at the clone implementation. Regards, Brandon -Original Message- From: gem5-dev On Behalf Of Maryam Babaie Sent: Friday, March 8, 2019 4:06 PM To: m5-...@m5sim.org Subject: [gem5-dev] Syscall_Emulation for Shared Memory Hi all, I have some questions regarding the system calls available in SE mode on gem5 for X86. I appreciate if any one shares their insight about them: 1. For the mmap syscall, the function "mmapImpl" has been implemented. Up-to which extend this function will work properly for mmap syscall? 2. For munmap syscall, they have put the munmapFunc, but the body of the corresponding function is actually empty. So, does this mean it is actually not supported on gem5? 3. msync syscall is flagged as unimplementedFunc. So, does this mean that mmap will still work but the writes will not be reflected persistently in the region? 4. Since the fork syscall is also flagged as unimplementedFunc , how is the concept of Copy on Write (generally shared pages) able to be simulated and handled in gem5? Regards ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Syscall_Emulation for Shared Memory
Hi all, I have some questions regarding the system calls available in SE mode on gem5 for X86. I appreciate if any one shares their insight about them: 1. For the mmap syscall, the function "mmapImpl" has been implemented. Up-to which extend this function will work properly for mmap syscall? 2. For munmap syscall, they have put the munmapFunc, but the body of the corresponding function is actually empty. So, does this mean it is actually not supported on gem5? 3. msync syscall is flagged as unimplementedFunc. So, does this mean that mmap will still work but the writes will not be reflected persistently in the region? 4. Since the fork syscall is also flagged as unimplementedFunc , how is the concept of Copy on Write (generally shared pages) able to be simulated and handled in gem5? Regards ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
