On Apr 11, 2016 22:31, "Jan Beulich" <jbeulich@suse.com> wrote:
>
> >>> Tamas K Lengyel <tamas@tklengyel.com> 04/11/16 9:47 PM >>>
> >--- a/xen/include/public/vm_event.h
> >+++ b/xen/include/public/vm_event.h
> >@@ -166,6 +166,31 @@ struct vm_event_regs_x86 {
>      >uint32_t _pad;
>  >};
>  >
> >+struct vm_event_regs_arm {
> >+    uint32_t r0;
> >+    uint32_t r1;
> >+    uint32_t r2;
> >+    uint32_t r3;
> >+    uint32_t r4;
> >+    uint32_t r5;
> >+    uint32_t r6;
> >+    uint32_t r7;
> >+    uint32_t r8;
> >+    uint32_t r9;
> >+    uint32_t r10;
> >+    uint32_t r11;
> >+    uint32_t r12;
> >+
> >+    uint32_t sp; /* r13 - SP: Valid for Hyp. frames only, o/w banked
(see below) */
> >+    uint32_t lr; /* r14 - LR: Valid for Hyp. Same physical register as
lr_usr. */
> >+
> >+    uint32_t cpsr; /* Return mode */
> >+    uint64_t pc;
>
> Why uint64_t instead of uint32_t?

No apparent reason, will fix.

>
> >+    uint64_t ttbr0;
> >+    uint64_t ttbr1;
> >+    uint32_t _pad;
> >+};
>
> This padding field is pretty strange: Without the adjustment to pc there
are 16
> 32-bit fields (not counting the padding one), so I don't see why padding
would be
> needed at all. And with pc adjusted the padding field would surely better
go
> ahead of the two remaining 64-bit ones.

Yes, I have been shuffling this struct around and didn't check the layout.
Will fix. I'll also try to make this struct usable for aarch64 too.

Tamas