kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  reply	other threads:[~2016-03-22 10:15 UTC|newest]

Thread overview: 25+ 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:53 ` [RFC PATCH 01/12] kvm arm: Move fake PGD handling to arch specific files 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-16 14:54   ` Marc Zyngier
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-16 15:01   ` Marc Zyngier
2016-03-16 15:37     ` Suzuki K. Poulose
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 17:06   ` Mark Rutland
2016-03-14 17:22     ` Suzuki K. Poulose
2016-03-22  8:55   ` Christoffer Dall
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 ` [RFC PATCH 06/12] kvm-arm: Pass kvm parameter for pagetable helpers Suzuki K Poulose
2016-03-22  9:30   ` Christoffer Dall
2016-03-22 10:15     ` Suzuki K. Poulose [this message]
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 ` [RFC PATCH 08/12] kvm: arm64: " 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 ` [RFC PATCH 10/12] kvm: arm64: Get rid of fake page table levels 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 ` [RFC PATCH 12/12] arm64: kvm: Add support for 16K pages 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 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).