On Tue, May 29, 2012 at 5:47 AM, Marc Zyngier <marc.zyngier at arm.com> wrote:
> Rework the HYP idmap code to be more consistent with what the kernel
> does:
>
> - Move the HYP pgd to the core code (so it can benefit to other
> ?hypervisors)
> - Populate this pgd with an identity mapping of the code contained
> ?in the .hyp_idmap.text section
> - Offer a method to drop the this identity mapping
the this?
> - Make all the above depend on CONFIG_ARM_VIRT_EXT
>
> This makes the core code more generic, and remove some of the
> clutter from the KVM init.
s/remove/removes/
[snip]
> diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
> index fffc01f..9f549c6 100644
> --- a/arch/arm/include/asm/pgtable.h
> +++ b/arch/arm/include/asm/pgtable.h
> @@ -315,9 +315,10 @@ static inline pte_t pte_modify(pte_t pte, pgprot_t newprot)
>
> ?#define pgtable_cache_init() do { } while (0)
>
> -#ifdef CONFIG_KVM_ARM_HOST
> -void hyp_idmap_add(pgd_t *, unsigned long, unsigned long);
> -void hyp_idmap_del(pgd_t *pgd, unsigned long addr, unsigned long end);
> +#ifdef CONFIG_ARM_VIRT_EXT
> +extern pgd_t *hyp_pgd;
hmm, I'm a bit worried about limiting the kernel to user only one
mapping in Hyp mode in general. What if there were several uses of
Hyp-mode on a given host system? Remapping the same virtual addresses
involves switching to Hyp-mode to flush TLBs etc. (iirc), so that
sounds almost impossible.
This approach actually seems less clean than the previous approach,
which was nicely contained to the use of KVM. Why would this be a
potential problem to merge?
[snip]
-Christoffer
