>>> On 30.05.16 at 00:37, <ta...@tklengyel.com> 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@lists.xen.org
http://lists.xen.org/xen-devel
