Am 08.06.2012 00:24, schrieb Richard Henderson:
> Signed-off-by: Richard Henderson <r...@twiddle.net>
> ---
> target-alpha/cpu.h | 11 +++++++++++
> 1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/target-alpha/cpu.h b/target-alpha/cpu.h
> index 99f9ee1..0d87fa7 100644
> --- a/target-alpha/cpu.h
> +++ b/target-alpha/cpu.h
> @@ -40,9 +40,20 @@
>
> #define TARGET_PAGE_BITS 13
>
> +#ifdef CONFIG_USER_ONLY
> +/* ??? The kernel likes to give addresses in high memory. If the host has
> + more virtual address space than the guest, this can lead to impossible
> + allocations. Honor the long-standing assumption that only kernel addrs
> + are negative, but otherwise allow allocations anywhere. This could lead
> + to tricky emulation problems for programs doing tagged addressing, but
> + that's far fewer than encounter the impossible allocation problem. */
> +#define TARGET_PHYS_ADDR_SPACE_BITS 63
> +#define TARGET_VIRT_ADDR_SPACE_BITS 63
> +#else
> /* ??? EV4 has 34 phys addr bits, EV5 has 40, EV6 has 44. */
> #define TARGET_PHYS_ADDR_SPACE_BITS 44
> #define TARGET_VIRT_ADDR_SPACE_BITS (30 + TARGET_PAGE_BITS)
> +#endif
>
> /* Alpha major type */
> enum {
This looks fishy to me... why should the kernel use a bigger address
space than hardware? For arm on x86_64 such a workaround was not
necessary iirc.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
