You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In our current FS configs, we claim that the whole range of 0 to mem_size is backed by memory, where as there are some (small) ranges (besides 3GB to 4GB reserved for IO) that are reserved for device specific features. For example, 0xC0000 is what kernel assumes the VGA rom to be located at by default (unless extended by ROM expansion BAR).
Creating a hole in our address range breaks several things in the code as we use mem_ranges in many other places (e.g. to create memory controllers etc.) and the code we have to merge the address ranges does not like the hole and would break on that. Point being, it's not gonna be simply adding a hole to the address range.
As @powerjg mentioned, we probably want to look at how it's done in real systems and provide similar functionality.
The way I have it currently implemented (on my local branch) is to add the small range to my check (for timing) and go to pio.
The text was updated successfully, but these errors were encountered:
Due to a 60GB limit on the VMs the gem5 project's GitHub Actions
self-hosted Runners execute within, we cannot run tests which need to
download the gem5 Resource's PARSEC disk image (v1.0.0,
http://resources.gem5.org/resources/x86-parsec?version=1.0.0). This
image, 33GB, is too big and causes our runners to run out of disk space
and fail.
These changes can be reverted when we are able to increase the size of
our VMs.
In our current FS configs, we claim that the whole range of 0 to mem_size is backed by memory, where as there are some (small) ranges (besides 3GB to 4GB reserved for IO) that are reserved for device specific features. For example, 0xC0000 is what kernel assumes the VGA rom to be located at by default (unless extended by ROM expansion BAR).
Creating a hole in our address range breaks several things in the code as we use mem_ranges in many other places (e.g. to create memory controllers etc.) and the code we have to merge the address ranges does not like the hole and would break on that. Point being, it's not gonna be simply adding a hole to the address range.
As @powerjg mentioned, we probably want to look at how it's done in real systems and provide similar functionality.
The way I have it currently implemented (on my local branch) is to add the small range to my check (for timing) and go to pio.
The text was updated successfully, but these errors were encountered: