From: jungseoklee85@gmail.com (Jungseok Lee)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v7 07/11] arm64: mm: Implement 4 levels of translation tables
Date: Wed, 30 Jul 2014 23:57:09 +0900 [thread overview]
Message-ID: <9DF712F2-52EB-412B-9E6F-41FC8212AE1F@gmail.com> (raw)
In-Reply-To: <53D7AD7A.8050706@amd.com>
On Jul 29, 2014, at 11:19 PM, Joel Schopp wrote:
>
>>> Here's a good example of where we run into trouble equating page table
>>> addressable bits with hardware addressable bits. If VA_BITS is 48 due
>>> to 4K 4 level page tables but is running on a 42 bit system this will
>>> end up being out of range.
>> Is your concern that CPU issues 48-bit address to MMU on 42-bit hardware?
>> Have you tested this patch series on your hardware?
>>
>> - Jungseok Lee
>
> That is my concern. I did test the patch on my hardware with the
> following results:
> 64k pages, 2 levels 42 bit VA - worked (no regression)
> 64k pages, 3 levels 48 bit VA- didn't boot
> 4k pages, 4 levels 42 bit VA - didn't boot
> 4k pages, 4 levels 48 bit VA - didn't boot
Let me break the concern down into two small parts.
The first one is a relation between VA and PA. Let me visualize the above
description in the following way. I assume that Cortex-A57 is used and
connected to bus with 42-bit address line.
SoC Boundary
|---------------------------------------------
| Cortex-A57 Boundary |
| --------------- |
| | CPU --> MMU | --> BUS --> Memory Controller --> RAM
| ------48------- 42 42 | 42
|---------------------------------------------
In this configuration, there is no problem since 48-bit VA is handled in
Cortex-A57 boundary. Cortex-A57 can support up to 48-bit VA and 44-bit PA.
The second part is the test result. It's bad actually. So, I've done booting
test on for-next/core branch of arm64 linux git, [1], quickly using Model. All
combinations, 4KB + 3Level (39-bit VA), 4KB + 4Level (48-bit VA), 64KB + 2Level
(42-bit VA) and 64KB + 3Level(48bit VA), boot up successfully.
I hesitate to say anything since I don't have any real hardware. I think people
who have real platform, such as Juno, can help to figure it out.
[1]: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
I add Will in Cc since [1] looks updated by Will now.
- Jungseok Lee
next prev parent reply other threads:[~2014-07-30 14:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAGoO6fLT6B_vx+Wtm6bKHD6YkjQcM8f=deD7SDP3BR_uC+1c5w@mail.gmail.com>
2014-07-29 13:47 ` [PATCH v7 07/11] arm64: mm: Implement 4 levels of translation tables Jungseok Lee
2014-07-29 14:19 ` Joel Schopp
2014-07-30 14:57 ` Jungseok Lee [this message]
2014-08-14 11:42 ` Ganapatrao Kulkarni
2014-08-14 12:58 ` Catalin Marinas
2014-08-14 13:47 ` Ganapatrao Kulkarni
[not found] <2211E520-32A4-435C-9F63-A7EFEE8B677A@gmail.com>
2014-07-17 15:04 ` Jungseok Lee
2014-07-17 16:47 ` Catalin Marinas
2014-07-16 19:09 [PATCH v7 00/11] arm64: Support " Catalin Marinas
2014-07-16 19:09 ` [PATCH v7 07/11] arm64: mm: Implement " Catalin Marinas
2014-07-28 15:40 ` Joel Schopp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9DF712F2-52EB-412B-9E6F-41FC8212AE1F@gmail.com \
--to=jungseoklee85@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).