Re: [Xen-devel] [PATCH v4 5/8] arm/vm_event: get/set registers

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 30.05.16 at 00:37, <tamas@xxxxxxxxxxxxx> wrote:
> +struct vm_event_regs_arm32 {
> +    uint32_t r0_usr;
> +    uint32_t r1_usr;
> +    uint32_t r2_usr;
> +    uint32_t r3_usr;
> +    uint32_t r4_usr;
> +    uint32_t r5_usr;
> +    uint32_t r6_usr;
> +    uint32_t r7_usr;
> +    uint32_t r8_usr;
> +    uint32_t r9_usr;
> +    uint32_t r10_usr;
> +    uint32_t r12_usr;
> +    uint32_t lr_usr;
> +    uint32_t fp;
> +    uint32_t pc;
> +    uint32_t sp_usr;
> +    uint32_t sp_svc;
> +    uint32_t spsr_svc;
> +};

It would seem more natural for the "ordinary" registers to be
arranged in the numerical sequence, i.e. fp, r12, sp, lr, pc.

> +struct vm_event_regs_arm64 {
> +    uint64_t x0;
> +    uint64_t x1;
> +    uint64_t x2;
> +    uint64_t x3;
> +    uint64_t x4;
> +    uint64_t x5;
> +    uint64_t x6;
> +    uint64_t x7;
> +    uint64_t x8;
> +    uint64_t x9;
> +    uint64_t x10;
> +    uint64_t x16;
> +    uint64_t lr;
> +    uint64_t fp;
> +    uint64_t pc;
> +    uint64_t sp_el0;
> +    uint64_t sp_el1;
> +    uint32_t spsr_el1;
> +    uint32_t _pad;
> +};

My ARM knowledge is certainly quite limited, but the incomplete set
of GPRs here is quite obvious: Is there a reason to not make all of
them available here? And if there is, could the criteria of which
registers got put here please be documented in a comment (so that
the next person noticing the incomplete set won't ask again)?

I'm also puzzled by fp and lr - I'm not aware of registers of those
names (and gas also doesn't accept them afaict).

> +struct vm_event_regs_arm {
> +    uint32_t cpsr; /* PSR_MODE_BIT is set iff arm32 is used below */

Explicit padding missing after this one.

Jan


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