[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RESEND PATCH v2 for-4.14] pvcalls: Document correctly and explicitely the padding for all arches



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



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.