remzi-arpacidusseau/ostep-homework

vm-mechanism: conflicting definitions of 'address space'

Opened this issue · 1 comments

Run relocation.py with the following arguments:

  • physical memory size: 8
  • address space size: 4
  • base register: 7
  • limit register: 2

and it reports that the address space does not fit into physical memory.

$ ./relocation.py -s 1 -p 8 -a 4 -b 7 -l 2

ARG seed 1
ARG address space size 4
ARG phys mem size 8

Base-and-Bounds register information:

  Base   : 0x00000007 (decimal 7)
  Limit  : 2

Error: address space does not fit into physical memory with those base/bounds values.
Base + Limit: 9   Psize: 8

Run it with these arguments:

  • physical memory size: 8
  • address space size: 4
  • base register: 6
  • limit register: 2

and it does not report an error.

$ ./relocation.py -s 1 -p 8 -a 4 -b 6 -l 2

ARG seed 1
ARG address space size 4
ARG phys mem size 8

Base-and-Bounds register information:

  Base   : 0x00000006 (decimal 6)
  Limit  : 2

Virtual Address Trace
  VA  0: 0x00000000 (decimal:    0) --> PA or segmentation violation?
  VA  1: 0x00000003 (decimal:    3) --> PA or segmentation violation?
  VA  2: 0x00000003 (decimal:    3) --> PA or segmentation violation?
  VA  3: 0x00000001 (decimal:    1) --> PA or segmentation violation?
  VA  4: 0x00000001 (decimal:    1) --> PA or segmentation violation?

For each virtual address, either write down the physical address it translates to
OR write down that it is an out-of-bounds address (a segmentation violation). For
this problem, you should assume a simple virtual address space of a given size.

This is confusing. Is the address space size defined by the limit register or the value of --asize/-a (address space size CLI argument)? In the examples above, since the address space size is explicitly set to 4 with the -a argument, I would expect both to throw the same error. Both are too close to the end of physical memory to fit an address space size of 4.

It appears that the --asize argument determines the range of random virtual addresses that are generated. Since not all of these generated addresses will lie in the "address space" of the underlying processes (as determined by the base/limit registers), perhaps the CLI argument -a should be renamed to something like "generated virtual address range" to avoid confusion.