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]; +#endifThere'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
