Thanks Gabe. I'll keeping digging to try and identify what is accessing this IO port.
If I understand your response correctly, it is also not a mapping problem in the config script -- because even if the script mapped this address, accessing the IO port from user-space would fail. Is that correct? Matt <http://rsim.cs.illinois.edu/%7Emdsincl2> On Sat, Feb 10, 2018 at 2:36 AM, Gabe Black <[email protected]> wrote: > It sounds to me like everything is working as intended. If there's nothing > backing IO port 72, then that's going to be an unmapped address. Also, if > you were to run a user space application on a real system, access to IO > port 72 most likely wouldn't be allowed at all since user space programs > aren't generally allowed to directly access physical resources like that. I > think there is a way to get Linux to let a particular process access > particular ports, but as far as I know that's not implemented in gem5. > > Gabe > > On Sat, Feb 10, 2018 at 12:23 AM, Matt Sinclair <[email protected]> > wrote: > >> Hi everyone, >> >> I've been getting the following error: >> >> fatal: Unable to find destination for addr 0x8000000000000048 on >> system.piobus >> >> The following microbenchmark reproduces the problem: >> >> #include <stdio.h> >> #include <stdlib.h> >> >> int main() >> { >> printf("doing test\n"); >> fflush(stdout); >> asm("in $72, %eax\n"); >> return 0; >> } >> >> To compile: gcc test.c -o test (I used gcc-5.4.0 to compile, in case that >> helps) >> >> To run: The simplest configuration this error occurs in is >> configs/learning_gem5/part1/simple.py (I changed the path/benchmark name >> to the test executable). The same error happens for other systems though. >> I ran it with the current HEAD of the public/gem5 branch. >> >> After looking through some traces, I noticed that the X86 "in" >> instruction is the source of this large address. More specifically, the >> address causing the problem is created when the PhysAddrPrefixIO (a >> constant set to 0x8000000000000000 in x86_traits.hh) is bitwise OR’d with >> the immediate (0x48) to create the physical address for the third micro-op >> of the "in" instruction in tlb.cc: translateInt(). Thus the (physical) >> address seems to be legitimate, but is not mapped and thus causes the above >> error. >> >> My question is: is this the expected behavior for the "in" instruction? >> If so, how should we go about mapping this address properly? Or is the >> mapping not the problem and the PhysAddrPrefixIO value is simply >> out-of-date? I noticed that PhysAddrPrefixIO was set to 0x8000000000000000 >> a long time ago. >> >> Thanks in advance for any help you may be able to provide. >> >> Thanks, >> Matt >> >> _______________________________________________ >> 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 >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
