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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html