[Top] [All Lists]

Re: [P5600 && EVA memory caching question] PCI region

To: James Hogan <>
Subject: Re: [P5600 && EVA memory caching question] PCI region
From: Yuri Frolov <>
Date: Fri, 15 Dec 2017 17:05:12 +0300
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=L108c2RYQVfbSSBJykedDU9j03DmiZ3R3pZXsKHPj4g=; b=bxdjOcyjZyDin8iuZLBO3JJXGng8zIQbZWPxPVzRIEsZ/tdTVWgOUNyMJYTX5o4hhx Y7xa9Cyu6qfp7SfRSOl/WAuiAeJmQx0uAdl8XQ1bw5117NsQbU0ou5ylyRuhgeKs4slg gzRpxCFCTAxL6YcICyP3YqDUbUheY3yXe8pKgK4mAwGk+ENt6zX+d9y7aQd65/hx4DXK 6ZggX4ktq9kjnEB8+ZTbKpRqo2JmMnpzYaVjmdtfnR6KvfrHQLMv9V+5endNfwsRcLJc 087iOfFJaxqvfzGGdW6zQgiZpWLwE6NRTxeQmCPNLK0WfcakJ5c3Gpauuxd1uP+J5qsf LO/A==
In-reply-to: <>
List-archive: <>
List-help: <>
List-id: linux-mips <>
List-owner: <>
List-post: <>
List-software: Ecartis version 1.0.0
List-subscribe: <>
List-unsubscribe: <>
Original-recipient: rfc822;
References: <> <> <> <>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
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

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))
l = *(u32 *)(0xc0040000+ 0x20)

should return the same value?

As for userspace addresses, the addresses from the 0x00000000 -
0xBFFFFFFF range are:
1) Overlayed with the range which is directly accessible from the kernel
Yes. Userland accesses access through tlb, kernel direct, and kernel eva
accesses (LWE/SWE etc) access through tlb from kernel

2) These addresses are mapped in userland, so, read from logical address
0x20000000 in userland may result in read from any physical address
located in range 0x00000000 - 0xBFFFFFFF as defined by TLB for that
particular userland thread?
Yes, though it could in theory be any physical address mapped by the
TLB, not just that range.


<Prev in Thread] Current Thread [Next in Thread>