[gem5-users] Re: BasicPioDevice read() / write() not responding
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
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
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
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
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
(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
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
