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

Reply via email to