On 03/08/2016 01:27 PM, David Miller wrote:
From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
Date: Tue, 8 Mar 2016 13:16:11 -0700
On 03/08/2016 12:57 PM, David Miller wrote:
From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
Date: Mon, 7 Mar 2016 14:06:43 -0700
Good questions. Isn't set of valid VAs already constrained by VA_BITS
(set to 44 in arch/sparc/include/asm/processor_64.h)? As I see it we
are already not using the top 4 bits. Please correct me if I am wrong.
Another limiting constraint is the number of address bits coverable by
the 4-level page tables we use. And this is sign extended so we have
a top-half and a bottom-half with a "hole" in the center of the VA
space.
I want some clarification on the top bits during ADI accesses.
If ADI is enabled, then the top bits of the virtual address are
intepreted as tag bits. Once "verified" with the ADI settings, what
happense to these tag bits? Are they dropped from the virtual address
before being passed down the TLB et al. for translations?
Bits 63-60 (tag bits) are dropped from the virtual address before
being passed down the TLB for translation when PSTATE.mcde = 1.
Ok and you said that values 15 and 0 are special.
I'm just wondering if this means you can't really use ADI mappings in
the top half of the 64-bit address space. If the bits are dropped, they
will be zero, but they need to be all 1's for the top-half of the VA
space since it's sign extended.
According to the manual when PSTATE.mcde=1, bits 63:60 of the virtual
address of any load or store (using virtual address) are masked before
being sent to memory system which includes MMU. Hardware TSB walker
masks bits 63:60 and then sign extends from bit 59 before generating TSB
pointer and before comparison to TSB TTE VAs but the virtual address in
the TTE tag that is written to DTLB is masked and not sign extended.
Manual also states that for implementations that fully support 60 bits
or more of virtual address, they must sign-extend virtual address in TSB
TTE tag.
--
Khalid
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
