[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v4 for-4.14 2/2] pvcalls: Document correctly and explicitely the padding for all arches
- To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
- From: Julien Grall <julien.grall.oss@xxxxxxxxx>
- Date: Fri, 10 Jul 2020 06:44:16 +0100
- Cc: Juergen Gross <jgross@xxxxxxxx>, Wei Liu <wl@xxxxxxx>, Paul Durrant <paul@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Julien Grall <jgrall@xxxxxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Fri, 10 Jul 2020 05:44:36 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Thu, 9 Jul 2020, Julien Grall wrote:
> Hi,
>
> Gentle ping.
>
> Is the new commit message fine?
>
> Cheers,
>
> On 04/07/2020 16:29, Julien Grall wrote:
> > Hi,
> >
> > On 27/06/2020 10: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
> > > the all architectures. The potential breakage of compatibility is ought
> > > 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>
> >
> > It looks like most of the comments are on the commit message. So rather than
> > sending the series again, below a new version of the commit message:
> >
> > "
> > 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 have a different size between
> > 32-bit x86 and 64-bit x86.
> >
> > For all the other architectures supported (Arm and 64-bit x86), the
> > structure have the sames sizes because they contain implicit padding thanks
> > to the 64-bit alinment of the field uint64_t field.
> >
> > Given the specification is authoritative, the padding will now be the same
> > for all architectures. The potential breakage of compatibility is ought to
> > be fine as pvcalls is still a tech preview.
> > "
Looks good to me
Acked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
Thanks! I don't have access to my work laptop today. Can any of the committers merge it so it doesn't miss 4.14?
Cheers,
|