On 1/7/22 07:23, Peter Maydell wrote:
On Wed, 8 Dec 2021 at 23:16, Richard Henderson
<[email protected]> wrote:
This feature is relatively small, as it applies only to
64k pages and thus requires no additional changes to the
table descriptor walking algorithm, only a change to the
minimum TSZ (which is the inverse of the maximum virtual
address space size).
Signed-off-by: Richard Henderson <[email protected]>
FEAT_LVA also expands the size of the VA field in
DBGBVR<n>_EL1. We currently hardcode the size of that
in hw_breakpoint_update() where we do:
addr = sextract64(bvr, 0, 49) & ~3ULL;
This is also true of DBGWVR<n>_EL1, except that there
we seem to have chosen to take advantage of the spec
defining the high bits of the register as RESS (ie
sign-extended) and we always use all of the address bits
regardless. Maybe we could do something similar with DBGBVR.
We treat DBGBVR and DBGWVR similarly, with the exception that DVGBVR is context dependent,
so we must wait until we interpret it together with DBGBCR.
However, I think the combination of IMPLEMENTATION DEFINED for storing the value as
written and CONSTRAINED UNPREDICTABLE for comparing the RESS bits means that we're allowed
to rely on Software to perform the appropriate extension and store and compare the entire
register.
I'll fix this in a separate patch.
r~
