[RFC PATCH 3/3] arm64: KVM: use ID map with increased VA range if required

[Catalin Marinas]

On Thu, Feb 26, 2015 at 03:29:07PM +0000, Ard Biesheuvel wrote:
> +	/*
> +	 * If we are running with VA_BITS < 48, we may be running with an extra
> +	 * level of translation in the ID map. This is only the case if system
> +	 * RAM is out of range for the currently configured page size and number
> +	 * of translation levels, in which case we will also need the extra
> +	 * level for the HYP ID map, or we won't be able to enable the EL2 MMU.
> +	 *
> +	 * However, at EL2, there is only one TTBR register, and we can't switch
> +	 * between translation tables *and* update TCR_EL2.T0SZ at the same
> +	 * time. Bottom line: we need the extra level in *both* our translation
> +	 * tables.

It doesn't sound too nice but I'm not sure we can do much about it.

> +	 *
> +	 * Fortunately, there is an easy way out: the existing ID map, with the
> +	 * extra level, can be reused for both. The kernel image is already
> +	 * identity mapped at a high virtual offset, which leaves VA_BITS of
> +	 * address space at the low end to put our runtime HYP mappings.
> +	 */

Another aspect here is that the Hyp VA starts at HYP_PAGE_OFFSET which
is 1 << (VA_BITS - 1). On some platforms we may get an overlap with the
physical memory (and the original idmap). Could we switch to the
dedicated hyp TTBR at this point, with the extra level? Functions like
__create_hyp_mapping() don't need to know about this extra level as
hyp_pgd only knows about 4 levels but TTBR0_EL2 would point to the extra
level.

-- 
Catalin