On Fri, Dec 15, 2017 at 05:05:12PM +0300, Yuri Frolov wrote: > Hi, James > > On 12/14/2017 06:21 PM, James Hogan wrote: > > Hi Yuri, > > > > On Thu, Dec 14, 2017 at 06:03:11PM +0300, Yuri Frolov wrote: > >> Hi, James. > >> > >> Do I understand correctly, that in case of CONFIG_EVA=y, any logical > >> address from 0x00000000 - 0xBFFFFFFF (3G) range accessed from the kernel > >> space is: > >> 1) Unmapped (no TLB translations) > >> 2) Is mapped 1:1 to physical addresses? E.g, readl from 0x20000000 is, > >> in fact a read from physical address 0x20000000? I mean, in legacy > >> memory mapping scheme, logical addresses 0x80000000 - 0xBFFFFFFF in > >> kernel space were being translated to the physical addresses from the > >> low 512Mb (phys 0x00000000 - 0x20000000), no such bits stripping or > >> something for EVA, the mapping is 1:1? > > That depends on the EVA configuration. The hardware is fairly flexible > > (which is both useful and painful - making supporting EVA from > > multiplatform kernels particularly awkward), but that is one possible > > configuration. > > > > E.g. ideally you probably want to keep seg5 (0x00000000..0x3FFFFFFF) > > MUSK (TLB mapped for user & kernel) so that null dereferences from > > kernel code are safely caught, but that costs you 1GB of directly > > accessible physical address space from kernel mode. > So, do I understand correctly, that provided we have these TLB entries > in kernel, > > Index: 71 pgmask=16kb va=c0038000 asid=00 > [ri=0 xi=0 pa=200e0000 c=2 d=1 v=1 g=1] [ri=0 xi=0 pa=00000000 > c=0 d=0 v=0 g=1] > Index: 72 pgmask=16kb va=c0040000 asid=00 > [ri=0 xi=0 pa=200c0000 c=2 d=1 v=1 g=1] [ri=0 xi=0 pa=200c4000 > c=2 d=1 v=1 g=1] > > u32 l; > > l = readl((const volatile void *)(0x200c0000 + 0x20)) assuming you have segment5 (0x00000000..0x3FFFFFFF) set to MUSUK, with PA 0 (i.e. direct 1:1 mapping), it'd access PA 0x200c0020, but presumably the segment will be configured to be cached (CCA 3) or cached coherent (CCA 5). > and > l = *(u32 *)(0xc0040000+ 0x20) this will access physical addres 0x200c0020 uncached (CCA 2). > > should return the same value? So that would depend I think on whether there is a dirty value in the cache. Possibly not. The cached mapping would see the dirty value. The uncached mapping may see a stale value straight from RAM. Cheers James
