[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 25/45] xen: arm: separate guest user regs from internal guest state.



So this ends up with two different layouts for core regs, one public and
one private, both of which have the padding/unions to allow 64-bit and
32-bit to coexist.  Can we really not re-use them?

At 15:56 +0000 on 23 Jan (1358956591), Ian Campbell wrote:
> +#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
> +# ifdef __aarch64__
> +/* Anonymous union includes both 32- and 64-bit names (e.g., r0/x0). */
> +#   define __DECL_REG(n64, n32) union {          \
> +        uint64_t n64;                            \
> +        uint32_t n32;                            \
> +    }
> +# else
> +/*
> + * Include a 64-bit padding field so that the layout is the same
> + * between 32- and 64-bit hypervisors.
> + */
> +#   define __DECL_REG(n64, n32) union {          \
> +        uint64_t __pad_##n64;                    \
> +        uint32_t n32;                            \
> +    }
> +# endif

On x86, a 32-bit toolstack can control 64-bit VMs.  We might want to
allow that on arm64 as well, so I'm not sureethe __pad prefix is useful.

Cheers,

Tim.

> +#else
> +/* Non-gcc sources must always use the proper 64-bit name (e.g., x0). */
> +#define __DECL_REG(n64, n32) uint64_t n64
> +#endif

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.