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
|