From: christoffer.dall@linaro.org (Christoffer Dall)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 15/17] kvm: arm64: Get rid of fake page table levels
Date: Tue, 12 Apr 2016 15:11:56 +0200 [thread overview]
Message-ID: <20160412131156.GH3039@cbox> (raw)
In-Reply-To: <570CF21D.8000600@arm.com>
On Tue, Apr 12, 2016 at 02:03:25PM +0100, Suzuki K Poulose wrote:
> On 12/04/16 13:14, Christoffer Dall wrote:
> >On Mon, Apr 11, 2016 at 03:33:45PM +0100, Suzuki K Poulose wrote:
> >>On 08/04/16 16:05, Christoffer Dall wrote:
> >>>On Mon, Apr 04, 2016 at 05:26:15PM +0100, Suzuki K Poulose wrote:
> >>
>
> >>>>-#if PGDIR_SHIFT > KVM_PHYS_SHIFT
> >>>>-#define PTRS_PER_S2_PGD_SHIFT 0
> >>>>-#else
> >>>>-#define PTRS_PER_S2_PGD_SHIFT (KVM_PHYS_SHIFT - PGDIR_SHIFT)
> >>>>-#endif
> >>>>-#define PTRS_PER_S2_PGD (1 << PTRS_PER_S2_PGD_SHIFT)
> >>>>+#define STAGE2_PGTABLE_LEVELS ARM64_HW_PGTABLE_LEVELS(KVM_PHYS_SHIFT - 4)
> >>>>
> >>>> /*
> >>>>- * If we are concatenating first level stage-2 page tables, we would have less
> >>>>- * than or equal to 16 pointers in the fake PGD, because that's what the
> >>>>- * architecture allows. In this case, (4 - CONFIG_PGTABLE_LEVELS)
> >>>>- * represents the first level for the host, and we add 1 to go to the next
> >>>>- * level (which uses contatenation) for the stage-2 tables.
> >
> >just noticed: s/contatenation/concatenation/
>
> Thanks for catching that. Will fix it.
>
> >>>which case this should be reworded to just state the assumptions and why
> >>>this is a good assumption.
> >>>
> >>>(If my assumptions are wrong here, then there are also weird cases where
> >>>the host does huge pages at the PMD level and we don't. Not sure I can
> >>>see the full ramifications of that.)
> >>
> >>I am sorry, I didn't get your point about the PMD level.
> >>
> >
> >Right, I expressed that terribly, and I may have gotten myself confused
> >when writing that.
> >
> >My concern is this: if the number of levels between the host and stage-2
> >are different, and the host uses huge pmd mappings (either THP or huge
> >tlb fs), then do we always do the right thing for stage-2 tables, even
> >if we support the case with more levels in Stage-2 than on the host?
>
> Yes. We are safe with PMD (level 2). In the worst case we will have a 2level
> page table at host and say 4 at stage2. In either case, we have a PMD level
> (which in host is folded to PGD) and both will use section mapping at level 2
> for huge pmd. Also pmd_huge() doesn't care if the PMD is folded or not. So,
> we are fine with that. I hope that answers your question.
>
It does, thanks for enumerating the cases for me.
> >
> >Thanks for trying to parse my crytptic and potentially nonsensical
> >questions.
>
> No no, they make absolute sense. I had gone through these questions myself initially
> when I wrote the series, so its good to share them :-).
>
> Btw, I have rebased my series to kvmarm and have addressed the comments. I will post
> them after a round of testing.
>
Great, thanks!
-Christoffer
next prev parent reply other threads:[~2016-04-12 13:11 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-04 16:26 [PATCH 00/17] kvm-arm: Add stage2 page table walker Suzuki K Poulose
2016-04-04 16:26 ` [PATCH 01/17] arm64: Reuse TCR field definitions for EL1 and EL2 Suzuki K Poulose
2016-04-08 12:43 ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 02/17] arm64: Cleanup VTCR_EL2 and VTTBR field values Suzuki K Poulose
2016-04-08 12:43 ` Christoffer Dall
2016-04-08 12:45 ` Suzuki K Poulose
2016-04-04 16:26 ` [PATCH 03/17] kvm arm: Move fake PGD handling to arch specific files Suzuki K Poulose
2016-04-04 16:26 ` [PATCH 04/17] arm64: Introduce pmd_thp_or_huge Suzuki K Poulose
2016-04-08 12:43 ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 05/17] kvm-arm: Replace kvm_pmd_huge with pmd_thp_or_huge Suzuki K Poulose
2016-04-08 12:43 ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 06/17] kvm-arm: Remove kvm_pud_huge() Suzuki K Poulose
2016-04-08 12:44 ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 07/17] kvm-arm: arm32: Introduce stage2 page table helpers Suzuki K Poulose
2016-04-08 12:43 ` Christoffer Dall
2016-04-08 14:39 ` Suzuki K Poulose
2016-04-04 16:26 ` [PATCH 08/17] kvm-arm: arm: Introduce hyp page table empty checks Suzuki K Poulose
2016-04-08 13:15 ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 09/17] kvm-arm: arm64: Introduce stage2 page table helpers Suzuki K Poulose
2016-04-08 13:15 ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 10/17] kvm-arm: arm64: Introduce hyp page table empty checks Suzuki K Poulose
2016-04-08 13:15 ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 11/17] kvm-arm: Use explicit stage2 helper routines Suzuki K Poulose
2016-04-08 13:16 ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 12/17] kvm-arm: Add explicit hyp page table modifiers Suzuki K Poulose
2016-04-08 13:15 ` Christoffer Dall
2016-04-08 15:09 ` Marc Zyngier
2016-04-08 15:16 ` Christoffer Dall
2016-04-08 15:22 ` Marc Zyngier
2016-04-08 15:22 ` Suzuki K Poulose
2016-04-08 15:25 ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 13/17] kvm-arm: Add stage2 " Suzuki K Poulose
2016-04-08 13:42 ` Christoffer Dall
2016-04-08 15:37 ` Suzuki K Poulose
2016-04-08 17:03 ` Christoffer Dall
2016-04-08 17:07 ` Suzuki K Poulose
2016-04-08 17:25 ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 14/17] kvm-arm: Cleanup kvm_* wrappers Suzuki K Poulose
2016-04-08 15:05 ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 15/17] kvm: arm64: Get rid of fake page table levels Suzuki K Poulose
2016-04-08 15:05 ` Christoffer Dall
2016-04-11 14:33 ` Suzuki K Poulose
2016-04-12 12:14 ` Christoffer Dall
2016-04-12 13:03 ` Suzuki K Poulose
2016-04-12 13:11 ` Christoffer Dall [this message]
2016-04-13 17:49 ` Suzuki K Poulose
2016-04-14 12:18 ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 16/17] kvm-arm: Cleanup stage2 pgd handling Suzuki K Poulose
2016-04-08 15:08 ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 17/17] arm64: kvm: Add support for 16K pages Suzuki K Poulose
2016-04-08 15:13 ` Christoffer Dall
2016-04-08 15:15 ` [PATCH 00/17] kvm-arm: Add stage2 page table walker Christoffer Dall
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=20160412131156.GH3039@cbox \
--to=christoffer.dall@linaro.org \
--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).