From: "Suzuki K. Poulose" <Suzuki.Poulose@arm.com>
To: Christoffer Dall <christoffer.dall@linaro.org>
Cc: marc.zyngier@arm.com, kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com,
kvm@vger.kernel.org, will.deacon@arm.com,
catalin.marinas@arm.com
Subject: Re: [RFC PATCH 06/12] kvm-arm: Pass kvm parameter for pagetable helpers
Date: Tue, 22 Mar 2016 10:15:11 +0000 [thread overview]
Message-ID: <56F11B2F.2080007@arm.com> (raw)
In-Reply-To: <20160322093037.GD21047@cbox>
On 22/03/16 09:30, Christoffer Dall wrote:
> On Mon, Mar 14, 2016 at 04:53:05PM +0000, Suzuki K Poulose wrote:
>> Pass 'kvm' to existing kvm_p.d_* page table wrappers to prepare
>> them to choose between hyp and stage2 page table. No functional
>> changes yet. Also while at it, convert them to static inline
>> functions.
>
> I have to say that I'm not really crazy about the idea of having common
> hyp and stage2 code and having the pgtable macros change behavior
> depending on the type.
>
> Is it not so that that host pgtable macros will always be valid for the
> hyp mappings, because we have the same VA space available etc.? It's
> just a matter of different page table entry attributes.
Yes, host pgtable macros are still used for hyp mappings, when kvm == NULL.
and we do use explicit accessors (stage2_xxx wherever possible with this series).
>
> Looking at arch/arm/kvm/mmu.c, it looks to me like we would get the
> cleanest separation by separating stuff that touches hyp page tables
> from stuff that touches stage2 page tables.
OK. Here are the routines which deal with both types:
unmap_range, unmap_p{u,m}ds, unmap_ptes, clear_p{g,u,m}_entry
Duplicating them won't be that much of trouble.
> Then you can get rid of the whole kvm_ prefix and directly use stage2
> accessors (which you may want to consider renaming to s2_) directly.
Right.
>
> I think we've seen in the past that the confusion from functions
> potentially touching both hyp and stage2 page tables is a bad thing and
> we should seek to avoid it.
OK, I will respin the series with the proposed changes.
Thanks
Suzuki
WARNING: multiple messages have this Message-ID (diff)
From: Suzuki.Poulose@arm.com (Suzuki K. Poulose)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 06/12] kvm-arm: Pass kvm parameter for pagetable helpers
Date: Tue, 22 Mar 2016 10:15:11 +0000 [thread overview]
Message-ID: <56F11B2F.2080007@arm.com> (raw)
In-Reply-To: <20160322093037.GD21047@cbox>
On 22/03/16 09:30, Christoffer Dall wrote:
> On Mon, Mar 14, 2016 at 04:53:05PM +0000, Suzuki K Poulose wrote:
>> Pass 'kvm' to existing kvm_p.d_* page table wrappers to prepare
>> them to choose between hyp and stage2 page table. No functional
>> changes yet. Also while at it, convert them to static inline
>> functions.
>
> I have to say that I'm not really crazy about the idea of having common
> hyp and stage2 code and having the pgtable macros change behavior
> depending on the type.
>
> Is it not so that that host pgtable macros will always be valid for the
> hyp mappings, because we have the same VA space available etc.? It's
> just a matter of different page table entry attributes.
Yes, host pgtable macros are still used for hyp mappings, when kvm == NULL.
and we do use explicit accessors (stage2_xxx wherever possible with this series).
>
> Looking at arch/arm/kvm/mmu.c, it looks to me like we would get the
> cleanest separation by separating stuff that touches hyp page tables
> from stuff that touches stage2 page tables.
OK. Here are the routines which deal with both types:
unmap_range, unmap_p{u,m}ds, unmap_ptes, clear_p{g,u,m}_entry
Duplicating them won't be that much of trouble.
> Then you can get rid of the whole kvm_ prefix and directly use stage2
> accessors (which you may want to consider renaming to s2_) directly.
Right.
>
> I think we've seen in the past that the confusion from functions
> potentially touching both hyp and stage2 page tables is a bad thing and
> we should seek to avoid it.
OK, I will respin the series with the proposed changes.
Thanks
Suzuki
next prev parent reply other threads:[~2016-03-22 10:15 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-14 16:52 [RFC PATCH 00/12] kvm-arm: Add stage2 page table walker Suzuki K Poulose
2016-03-14 16:52 ` Suzuki K Poulose
2016-03-14 16:53 ` [RFC PATCH 01/12] kvm arm: Move fake PGD handling to arch specific files Suzuki K Poulose
2016-03-14 16:53 ` Suzuki K Poulose
2016-03-14 16:53 ` [RFC PATCH 02/12] arm64: kvm: Fix {V}TCR_EL2_TG0 mask Suzuki K Poulose
2016-03-14 16:53 ` Suzuki K Poulose
2016-03-16 14:54 ` Marc Zyngier
2016-03-16 14:54 ` Marc Zyngier
2016-03-16 15:35 ` Suzuki K. Poulose
2016-03-16 15:35 ` Suzuki K. Poulose
2016-03-14 16:53 ` [RFC PATCH 03/12] arm64: kvm: Cleanup VTCR_EL2/VTTBR computation Suzuki K Poulose
2016-03-14 16:53 ` Suzuki K Poulose
2016-03-16 15:01 ` Marc Zyngier
2016-03-16 15:01 ` Marc Zyngier
2016-03-16 15:37 ` Suzuki K. Poulose
2016-03-16 15:37 ` Suzuki K. Poulose
2016-03-16 15:45 ` Marc Zyngier
2016-03-16 15:45 ` Marc Zyngier
2016-03-14 16:53 ` [RFC PATCH 04/12] kvm-arm: Rename kvm_pmd_huge to huge_pmd Suzuki K Poulose
2016-03-14 16:53 ` Suzuki K Poulose
2016-03-14 17:06 ` Mark Rutland
2016-03-14 17:06 ` Mark Rutland
2016-03-14 17:22 ` Suzuki K. Poulose
2016-03-14 17:22 ` Suzuki K. Poulose
2016-03-22 8:55 ` Christoffer Dall
2016-03-22 8:55 ` Christoffer Dall
2016-03-22 10:03 ` Suzuki K. Poulose
2016-03-22 10:03 ` Suzuki K. Poulose
2016-03-14 16:53 ` [RFC PATCH 05/12] kvm-arm: Move kvm_pud_huge to arch specific headers Suzuki K Poulose
2016-03-14 16:53 ` Suzuki K Poulose
2016-03-14 16:53 ` [RFC PATCH 06/12] kvm-arm: Pass kvm parameter for pagetable helpers Suzuki K Poulose
2016-03-14 16:53 ` Suzuki K Poulose
2016-03-22 9:30 ` Christoffer Dall
2016-03-22 9:30 ` Christoffer Dall
2016-03-22 10:15 ` Suzuki K. Poulose [this message]
2016-03-22 10:15 ` Suzuki K. Poulose
2016-03-22 10:30 ` Christoffer Dall
2016-03-22 10:30 ` Christoffer Dall
2016-03-14 16:53 ` [RFC PATCH 07/12] kvm: arm: Introduce stage2 page table helpers Suzuki K Poulose
2016-03-14 16:53 ` Suzuki K Poulose
2016-03-14 16:53 ` [RFC PATCH 08/12] kvm: arm64: " Suzuki K Poulose
2016-03-14 16:53 ` Suzuki K Poulose
2016-03-14 16:53 ` [RFC PATCH 09/12] kvm-arm: Switch to kvm pagetable helpers Suzuki K Poulose
2016-03-14 16:53 ` Suzuki K Poulose
2016-03-14 16:53 ` [RFC PATCH 10/12] kvm: arm64: Get rid of fake page table levels Suzuki K Poulose
2016-03-14 16:53 ` Suzuki K Poulose
2016-03-14 16:53 ` [RFC PATCH 11/12] kvm-arm: Cleanup stage2 pgd handling Suzuki K Poulose
2016-03-14 16:53 ` Suzuki K Poulose
2016-03-14 16:53 ` [RFC PATCH 12/12] arm64: kvm: Add support for 16K pages Suzuki K Poulose
2016-03-14 16:53 ` Suzuki K Poulose
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=56F11B2F.2080007@arm.com \
--to=suzuki.poulose@arm.com \
--cc=catalin.marinas@arm.com \
--cc=christoffer.dall@linaro.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=marc.zyngier@arm.com \
--cc=mark.rutland@arm.com \
--cc=will.deacon@arm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.