Hi,
On 27/06/2020 10:55, Julien Grall wrote:
From: Julien Grall <[email protected]>
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 <[email protected]>
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.
"
Cheers,
--
Julien Grall
