Re: [Xen-devel] [PATCH] vm_event: Implement ARM SMC events

["Jan Beulich" <jbeulich@xxxxxxxx>]

>>> Tamas K Lengyel <tamas@xxxxxxxxxxxxx> 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?

>+    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.

>@@ -254,6 +279,7 @@ typedef struct vm_event_st {
     >union {
         >union {
             >struct vm_event_regs_x86 x86;
>+            struct vm_event_regs_arm arm;
         >} regs;
 
         Does this alter the x86 ABI? Perhaps the ARM structure is small enough 
for
this to not happen now, but what's the general idea about not breaking other
arch'es ABIs when adding support for a new arch here?

Jan


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