[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH] vm_event: Implement ARM SMC events
On Apr 11, 2016 22:31, "Jan Beulich" <jbeulich@xxxxxxxx> wrote:
>
> >>> 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?
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
