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