[gem5-users] Re: BasicPioDevice read() / write() not responding

2021-10-23 Thread Gabe Black via gem5-users
I agree with Hoa that you're using virtual addresses, and those are
unrelated to the physical addresses you're trying to access. The second
method is probably moving an immediate constant into the register, and not
loading from a memory address. mmap-ing the physical pages you're
interested in would help. Also you should use the "volatile" keyword to
tell the compiler that this isn't just memory, and it shouldn't assume that
the value won't change out from under it, and hence it needs to read from
it or write to it for real every time you tell it to. If you're using
caches, you'll also want to make sure that range is not cached, or the
accesses will be handled by the cache and not actually make it out to the
rest of the memory system.

Gabe

On Sat, Oct 23, 2021 at 7:02 PM Hoa Nguyen via gem5-users <
gem5-users@gem5.org> wrote:

> Hi Andreas,
>
> My guess is that for Method 1, the pointer is of a virtual address so
> there's a page fault there.
>
> I'm not sure why the write() function wasn't invoked on Method 2. I got
> into the same problem recently where I used mmap() to write to a physical
> address, which should be handled by a Pio device. Even though the generated
> binary has a store instruction to that address, the write() function wasn't
> called. I solved that problem by using printf() to print the value at that
> physical address. I think using volatile keyword should have worked as well.
>
> I'm quite rusty on bare metal programming so I might be wrong :)
>
> Regards,
> Hoa Nguyen
>
> On Sat, Oct 23, 2021, 4:37 PM diavastos--- via gem5-users <
> gem5-users@gem5.org> wrote:
>
>> Hi all,
>>
>> I implemented a device using the BasicPioDevice class but I can't seem to
>> get the read() & write() calls to work.
>> I assigned a pioAddr=0x2 and a pioSize=4096 and I try to write to
>> the device directly using these two methods:
>>
>> Method 1:
>> ---
>>
>> uint32_t inp_params2 = 14;
>> uint64_t *driver = (uint64_t*)0x2;
>> *driver = inp_params2;
>>
>> Method 2:
>> ---
>>
>> asm volatile (
>> "mov %0,0x2\n"
>> :
>> : "r" (inp_params2)
>> :
>> );
>>
>> With the Method 2, the simulation completes with no error but the write()
>> is never called on the device, With Method 1 I get the following error:
>> panic: panic condition !handled occurred: Page table fault when accessing
>> virtual address 0x2
>>
>> Any help would be greatly appreciated!
>>
>> Many Thanks,
>> andreas
>> ___
>> gem5-users mailing list -- gem5-users@gem5.org
>> To unsubscribe send an email to gem5-users-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: BasicPioDevice read() / write() not responding

2021-10-23 Thread Hoa Nguyen via gem5-users
Hi Andreas,

My guess is that for Method 1, the pointer is of a virtual address so
there's a page fault there.

I'm not sure why the write() function wasn't invoked on Method 2. I got
into the same problem recently where I used mmap() to write to a physical
address, which should be handled by a Pio device. Even though the generated
binary has a store instruction to that address, the write() function wasn't
called. I solved that problem by using printf() to print the value at that
physical address. I think using volatile keyword should have worked as well.

I'm quite rusty on bare metal programming so I might be wrong :)

Regards,
Hoa Nguyen

On Sat, Oct 23, 2021, 4:37 PM diavastos--- via gem5-users <
gem5-users@gem5.org> wrote:

> Hi all,
>
> I implemented a device using the BasicPioDevice class but I can't seem to
> get the read() & write() calls to work.
> I assigned a pioAddr=0x2 and a pioSize=4096 and I try to write to
> the device directly using these two methods:
>
> Method 1:
> ---
>
> uint32_t inp_params2 = 14;
> uint64_t *driver = (uint64_t*)0x2;
> *driver = inp_params2;
>
> Method 2:
> ---
>
> asm volatile (
> "mov %0,0x2\n"
> :
> : "r" (inp_params2)
> :
> );
>
> With the Method 2, the simulation completes with no error but the write()
> is never called on the device, With Method 1 I get the following error:
> panic: panic condition !handled occurred: Page table fault when accessing
> virtual address 0x2
>
> Any help would be greatly appreciated!
>
> Many Thanks,
> andreas
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] BasicPioDevice read() / write() not responding

2021-10-23 Thread diavastos--- via gem5-users
Hi all,

I implemented a device using the BasicPioDevice class but I can't seem to get 
the read() & write() calls to work. 
I assigned a pioAddr=0x2 and a pioSize=4096 and I try to write to the 
device directly using these two methods:

Method 1:
---

uint32_t inp_params2 = 14;
uint64_t *driver = (uint64_t*)0x2;
*driver = inp_params2;

Method 2:
---

asm volatile (
"mov %0,0x2\n"
:
: "r" (inp_params2)
:
);

With the Method 2, the simulation completes with no error but the write() is 
never called on the device, With Method 1 I get the following error:
panic: panic condition !handled occurred: Page table fault when accessing 
virtual address 0x2

Any help would be greatly appreciated!

Many Thanks,
andreas
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s


[gem5-users] Re: MOESI_AMD_Base-CorePair.sm and MOESI_AMD_Base-dir.sm Correctness Check

2021-10-23 Thread Matt Sinclair via gem5-users
Yes, I understood this is what you meant.  The point I was trying to make
is I have not examined a trace to see what is actually happening (have you
gotten a trace to examine what's happening with the DataBlk value for this
request?).  After digging in a little further, it appears that this line:
https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/src/mem/ruby/protocol/MOESI_AMD_Base-dir.sm#878
will be allocating a directory entry if it doesn't exist already
(build/.../mem/ruby/protocol/Directory_Controller.cc:2022).  Since the
state is already U in the transition you are highlighting, I'm assuming the
DirectoryEntry already exists.  So the allocation would not need to happen,
and thus they'd be taking whatever data entry is already there (it is
unclear to me what happens if the directory entry is being allocated ...
because then there would be no data block to start with).  It certainly
appears that vd_victim is not treating the request it creates as a
writethrough, which is the only case in the directory right now where it
updates the TBE entry from the incoming message.

This kind of stuff is tricky though, and there may be other assumptions
elsewhere I haven't seen that explain it.  So I'd want someone to look at a
trace and see if the DataBlk is being updated despite my initial read being
that something isn't quite right.  Hence, getting a trace -- and likely
adding some DPRINTFs for the ProtocolTrace flag that print out DataBlk at
the beginning and end of this action would be important.

Brad, do you remember if the data values are truly being copied by Ruby
now?  I believe the functional accesses are no longer separate?  If not,
then it perhaps explains why this potential bug hasn't been caught before
(since it's a benign bug).  If so, then it does seem like this would affect
correctness.

My guess is it would be a copy partial if this change is needed -- in case
the prior level of cache only wrote specific words on the line, you'd only
want to update those words.  I could imagine multiple protocols connecting
to the directory, and thus while any one of them might update all of the
words on the line, to ensure correctness for both protocols that write
specific words and ones that write the entire line.

Matt

On Sat, Oct 23, 2021 at 1:53 PM Sampad Mohapatra  wrote:

> Hi Matt,
>
> The following condition is missing in t_allocateTBE, but the corepair
> sends a message with VicDirty - CoherenceRequestType.
>
> if (in_msg.Type == CoherenceRequestType:VicDirty) {
>   tbe.DataBlk = in_msg.DataBlk;
> }
>
> P.S.: I am not sure whether the complete block should be replaced or just
> partially copied.
>
> Thanks,
> Sampad
>
> On Sat, Oct 23, 2021 at 2:44 PM Matt Sinclair <
> mattdsinclair.w...@gmail.com> wrote:
>
>> (Resending to mailing list)
>>
>> Hi Sampad,
>>
>> There are lines directly below the one I pointed to that do potentially
>> overwrite the data there.  But I am not 100% sure -- Brad and Matt P, CC'd
>> may know better or see something I'm missing.
>>
>> Matt
>>
>> On Sat, Oct 23, 2021 at 1:37 PM Sampad Mohapatra  wrote:
>>
>>> Yes, but the data is coming from the directory and not the incoming
>>> message, which has the actual data.
>>>
>>> Should it not be:
>>> *tbe.DataBlk := in_msg.DataBlk;*
>>>
>>> i.e., store the dirty victim block data in the tbe.
>>>
>>> Thanks,
>>> Sampad
>>>
>>> On Sat, Oct 23, 2021 at 1:00 PM Matt Sinclair <
>>> mattdsinclair.w...@gmail.com> wrote:
>>>
 I am not sure I understand completely what you're getting at, but it
 appears the allocation of the TBE entry does store the data:
 https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/src/mem/ruby/protocol/MOESI_AMD_Base-dir.sm#878

 Matt

 On Thu, Oct 21, 2021 at 11:08 PM Sampad Mohapatra via gem5-users <
 gem5-users@gem5.org> wrote:

> Hello All,
>
> I was looking at the MOESI_AMD_Base-CorePair.sm and
> MOESI_AMD_Base-dir.sm and am not quite sure if the following sequence of
> events are correct or not. Can you please verify?
>
> /
> At CorePair -> invokes action "vd_victim", which sends a data block
> with outgoing message.
>
> At Directory -> undergoes "transition(U, VicDirty, BL)" on message
> reception, but doesn't store the received data block in the generated TBE
> and the message is popped out/discarded.
> /
>
> Is the above expected behaviour ?
>
> Thanks and regards,
> Sampad Mohapatra
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s


___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: MOESI_AMD_Base-CorePair.sm and MOESI_AMD_Base-dir.sm Correctness Check

2021-10-23 Thread Sampad Mohapatra via gem5-users
Hi Matt,

The following condition is missing in t_allocateTBE, but the corepair sends
a message with VicDirty - CoherenceRequestType.

if (in_msg.Type == CoherenceRequestType:VicDirty) {
  tbe.DataBlk = in_msg.DataBlk;
}

P.S.: I am not sure whether the complete block should be replaced or just
partially copied.

Thanks,
Sampad

On Sat, Oct 23, 2021 at 2:44 PM Matt Sinclair 
wrote:

> (Resending to mailing list)
>
> Hi Sampad,
>
> There are lines directly below the one I pointed to that do potentially
> overwrite the data there.  But I am not 100% sure -- Brad and Matt P, CC'd
> may know better or see something I'm missing.
>
> Matt
>
> On Sat, Oct 23, 2021 at 1:37 PM Sampad Mohapatra  wrote:
>
>> Yes, but the data is coming from the directory and not the incoming
>> message, which has the actual data.
>>
>> Should it not be:
>> *tbe.DataBlk := in_msg.DataBlk;*
>>
>> i.e., store the dirty victim block data in the tbe.
>>
>> Thanks,
>> Sampad
>>
>> On Sat, Oct 23, 2021 at 1:00 PM Matt Sinclair <
>> mattdsinclair.w...@gmail.com> wrote:
>>
>>> I am not sure I understand completely what you're getting at, but it
>>> appears the allocation of the TBE entry does store the data:
>>> https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/src/mem/ruby/protocol/MOESI_AMD_Base-dir.sm#878
>>>
>>> Matt
>>>
>>> On Thu, Oct 21, 2021 at 11:08 PM Sampad Mohapatra via gem5-users <
>>> gem5-users@gem5.org> wrote:
>>>
 Hello All,

 I was looking at the MOESI_AMD_Base-CorePair.sm and
 MOESI_AMD_Base-dir.sm and am not quite sure if the following sequence of
 events are correct or not. Can you please verify?

 /
 At CorePair -> invokes action "vd_victim", which sends a data block
 with outgoing message.

 At Directory -> undergoes "transition(U, VicDirty, BL)" on message
 reception, but doesn't store the received data block in the generated TBE
 and the message is popped out/discarded.
 /

 Is the above expected behaviour ?

 Thanks and regards,
 Sampad Mohapatra
 ___
 gem5-users mailing list -- gem5-users@gem5.org
 To unsubscribe send an email to gem5-users-le...@gem5.org
 %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>>
>>>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: MOESI_AMD_Base-CorePair.sm and MOESI_AMD_Base-dir.sm Correctness Check

2021-10-23 Thread Matt Sinclair via gem5-users
 (Resending to mailing list)

Hi Sampad,

There are lines directly below the one I pointed to that do potentially
overwrite the data there.  But I am not 100% sure -- Brad and Matt P, CC'd
may know better or see something I'm missing.

Matt

On Sat, Oct 23, 2021 at 1:37 PM Sampad Mohapatra  wrote:

> Yes, but the data is coming from the directory and not the incoming
> message, which has the actual data.
>
> Should it not be:
> *tbe.DataBlk := in_msg.DataBlk;*
>
> i.e., store the dirty victim block data in the tbe.
>
> Thanks,
> Sampad
>
> On Sat, Oct 23, 2021 at 1:00 PM Matt Sinclair <
> mattdsinclair.w...@gmail.com> wrote:
>
>> I am not sure I understand completely what you're getting at, but it
>> appears the allocation of the TBE entry does store the data:
>> https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/src/mem/ruby/protocol/MOESI_AMD_Base-dir.sm#878
>>
>> Matt
>>
>> On Thu, Oct 21, 2021 at 11:08 PM Sampad Mohapatra via gem5-users <
>> gem5-users@gem5.org> wrote:
>>
>>> Hello All,
>>>
>>> I was looking at the MOESI_AMD_Base-CorePair.sm and
>>> MOESI_AMD_Base-dir.sm and am not quite sure if the following sequence of
>>> events are correct or not. Can you please verify?
>>>
>>> /
>>> At CorePair -> invokes action "vd_victim", which sends a data block with
>>> outgoing message.
>>>
>>> At Directory -> undergoes "transition(U, VicDirty, BL)" on message
>>> reception, but doesn't store the received data block in the generated TBE
>>> and the message is popped out/discarded.
>>> /
>>>
>>> Is the above expected behaviour ?
>>>
>>> Thanks and regards,
>>> Sampad Mohapatra
>>> ___
>>> gem5-users mailing list -- gem5-users@gem5.org
>>> To unsubscribe send an email to gem5-users-le...@gem5.org
>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>
>>
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: MOESI_AMD_Base-CorePair.sm and MOESI_AMD_Base-dir.sm Correctness Check

2021-10-23 Thread Matt Sinclair via gem5-users
I am not sure I understand completely what you're getting at, but it
appears the allocation of the TBE entry does store the data:
https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/src/mem/ruby/protocol/MOESI_AMD_Base-dir.sm#878

Matt

On Thu, Oct 21, 2021 at 11:08 PM Sampad Mohapatra via gem5-users <
gem5-users@gem5.org> wrote:

> Hello All,
>
> I was looking at the MOESI_AMD_Base-CorePair.sm and MOESI_AMD_Base-dir.sm
> and am not quite sure if the following sequence of events are correct or
> not. Can you please verify?
>
> /
> At CorePair -> invokes action "vd_victim", which sends a data block with
> outgoing message.
>
> At Directory -> undergoes "transition(U, VicDirty, BL)" on message
> reception, but doesn't store the received data block in the generated TBE
> and the message is popped out/discarded.
> /
>
> Is the above expected behaviour ?
>
> Thanks and regards,
> Sampad Mohapatra
> ___
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s