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
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
