> -----Original Message----- > From: Jürgen Groß <jgr...@suse.com> > Sent: 27 June 2020 12:54 > To: Julien Grall <jul...@xen.org>; xen-devel@lists.xenproject.org > Cc: p...@xen.org; Julien Grall <jgr...@amazon.com>; Andrew Cooper > <andrew.coop...@citrix.com>; George > Dunlap <george.dun...@citrix.com>; Ian Jackson <ian.jack...@eu.citrix.com>; > Jan Beulich > <jbeul...@suse.com>; Stefano Stabellini <sstabell...@kernel.org>; Wei Liu > <w...@xen.org> > 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 <jgr...@amazon.com> > > > > 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 <jgr...@amazon.com> > > With above fixed: > > Reviewed-by: Juergen Gross <jgr...@suse.com> >
Release-acked-by: Paul Durrant <p...@xen.org> > > Juergen
