RE: [PATCH v4 for-4.14 2/2] pvcalls: Document correctly and explicitely the padding for all arches

[Paul Durrant <xadimgnik@xxxxxxxxx>]

> -----Original Message-----
> From: Jürgen Groß <jgross@xxxxxxxx>
> Sent: 27 June 2020 12:54
> To: Julien Grall <julien@xxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx
> Cc: paul@xxxxxxx; Julien Grall <jgrall@xxxxxxxxxx>; Andrew Cooper 
> <andrew.cooper3@xxxxxxxxxx>; George
> Dunlap <george.dunlap@xxxxxxxxxx>; Ian Jackson <ian.jackson@xxxxxxxxxxxxx>; 
> Jan Beulich
> <jbeulich@xxxxxxxx>; Stefano Stabellini <sstabellini@xxxxxxxxxx>; Wei Liu 
> <wl@xxxxxxx>
> Subject: Re: [PATCH v4 for-4.14 2/2] pvcalls: Document correctly and 
> explicitely the padding for all
> arches
> 
> On 27.06.20 11:55, Julien Grall wrote:
> > From: Julien Grall <jgrall@xxxxxxxxxx>
> >
> > The specification of pvcalls suggests there is padding for 32-bit x86
> > at the end of most the structure. However, they are not described in
> > in the public header.
> >
> > Because of that all the structures would be 32-bit aligned and not
> > 64-bit aligned for 32-bit x86.
> >
> > For all the other architectures supported (Arm and 64-bit x86), the
> > structure are aligned to 64-bit because they contain uint64_t field.
> > Therefore all the structures contain implicit padding.
> >
> > Given the specification is authoriitative, the padding will the same for
> 
> s/authoriitative/authoritative/
> 
> > the all architectures. The potential breakage of compatibility is ought
> 
> s/the//
> 
> > to be fine as pvcalls is still a tech preview.
> >
> > As an aside, the padding sadly cannot be mandated to be 0 as they are
> > already present. So it is not going to be possible to use the padding
> > for extending a command in the future.
> >
> > Signed-off-by: Julien Grall <jgrall@xxxxxxxxxx>
> 
> With above fixed:
> 
> Reviewed-by: Juergen Gross <jgross@xxxxxxxx>
> 

Release-acked-by: Paul Durrant <paul@xxxxxxx>

> 
> Juergen