Re: Is: ARM maintainers advice ..Was:Re: [PATCH v5 11/28] xsplice: Implement support for applying/reverting/replacing patches.

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Mon, Apr 11, 2016 at 09:44:55AM -0600, Jan Beulich wrote:
> >>> On 10.04.16 at 21:47, <konrad.wilk@oracle.com> wrote:
> > That allows the size and offsets to be the same. I checked under ARM32
> > builds:
> > 
> > 
> > struct xsplice_patch_func_internal {
> >     const char  *              name;                 /*     0     4 */
> >     uint32_t                   _pad0;                /*     4     4 */
> >     void *                     new_addr;             /*     8     4 */
> >     uint32_t                   _pad1;                /*    12     4 */
> >     void *                     old_addr;             /*    16     4 */
> >     uint32_t                   _pad2;                /*    20     4 */
> >     uint32_t                   new_size;             /*    24     4 */
> >     uint32_t                   old_size;             /*    28     4 */
> >     uint8_t                    version;              /*    32     1 */
> >     union {
> >         uint8_t            pad[31];              /*          31 */
> >     } u;                                             /*    33    31 */
> >     /* --- cacheline 1 boundary (64 bytes) --- */
> > 
> >     /* size: 64, cachelines: 1, members: 10 */
> > };
> > 
> > So it all looks correct. (and I can cast the old_addr to uint8_t).
> > Naturally we can expand the pad[] to hold whatever is needed
> > when implementing xSplice under ARM
> 
> I still don't get: Why is it so important for this structure to have
> the same size and layout across architectures?

I have a very bad taste from the blkif.h struct request where the structure
size is 112 or 108 depending on the 32 vs 64.

Having the same offsets for variables should make it easier for the
tools to generate the payload much simpler without having to worry
about the sizes or offset. Also it means that the common code BUILT_IN_BUG
can be generic across ARM and x86.

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