On other architectures, the address is a PTE stored using field_high and
thus retrieved as an aligned address. On RISCV we have a frame number
(referred to as PPN in some places) that is the address shifted down by
pt_bits.
This changes over the pte to use a ppn with a different number of bits,
and provides addr_from_ppn and addr_from_pte accessors, the latter being
an abbreviation.
Issues:
- "ppn" and "frame" show up in C, which should we use
- conversion functions take paddr, but are named with "addr": change
naming to use paddr?
- we sanity check the number of bits in a ppn is word_bits - pt_bits,
but in C that number subtracts another 8 bits, not clear why
1 sorry left, which should disappear after sync with work in ArchAcc_AI.
Strengthened valid_asid_pool_caps invariant to same phrasing as valid_vs_lookup
to get uniform preconditions for set_cap.
Strengthened reachable_target to actually cover all reachable targets of a
lookup (incl ASIDPools).
We previously had the user region from 0 to user_vtop, which does not
necessarily include all canonical addresses in the low range. However, even if
users are not able to map anything above user_vtop, they can still access a
virtual address > user_vtop, and our invariants cover this case. (Either the
address will simply not be mapped or it will be a lookup into the kernel part
of the vspace, i.e. a page fault for the user).
This commit introduces canonical_user as the largest canonical address in the
low range of canonical addresses, which is the range reserved for users.
RISCV faults reduced to actual VM faults, rest become anonymous user-level
faults. handleVMFault adjusted to perform complete case distinction and to not
change the state.
Now in sync with seL4 master@a39c9b6a76d279364e28d3415d750d7287fefd67
C now has a user_vtop different from pptr_base, so valid_uses needed updating,
and since the intervals don't fully join up any more, also strengthening of the
user and kernel window properties.
To make sure this is all still consistent, there is now an example state in
ArchKernelInit_AI that is shown to satisfy these conditions.
Previously valid_global_tables was nor deriveable from invs.
The best place I could think to put it is inside valid_arch_state.
This made a mess of some valid_arch_state_lift-related lemmas and
trivial valid_arch_state preservation in two cases, but seems a decent
tradeoff.
Rafal Kolanski
Gerwin Klein