Re: [RESEND PATCH v2 for-4.14] pvcalls: Document correctly and explicitely the padding for all arches

[Julien Grall <julien@xxxxxxx>]

Hi Jan,

On 18/05/2020 12:51, Jan Beulich wrote:
> On 16.05.2020 12:21, Julien Grall wrote:
> > --- a/xen/include/public/io/pvcalls.h
> > +++ b/xen/include/public/io/pvcalls.h
> > @@ -65,6 +65,9 @@ struct xen_pvcalls_request {
> >               uint32_t domain;
> >               uint32_t type;
> >               uint32_t protocol;
> > +#ifndef CONFIG_X86_32
> > +            uint8_t pad[4];
> > +#endif
> There's no concept of CONFIG_* in the public headers, the dependency
> (as you'll find elsewhere) is on __i386__ / __x86_64__.
Doh, I forgot it. I will fix it.

> Also whether
> there's any padding really doesn't depend directly on the architecture,
> but instead on __alignof__(uint64_t) (i.e. a future port to a 32-bit
> arch, even if - like on x86 - just a guest bitness, may similarly
> want / need / have no padding here).
Lets imagine someone decide to introduce 32-bit and then later on 
64-bit. Both have different padding requirements. This would result to 
the same mess as on x86.
So I think we shouldn't depend on __alignof__(uint64_t) to avoid any 
more screw up. Obviously extra care would need to be taken if the 
padding is higher, but it is also true in many other place of Xen headers.
Cheers,

--
Julien Grall