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

Re: [PATCH] pvcalls: Document explicitly the padding for all arches

On 29/04/2020 15:56, Jan Beulich wrote:
On 29.04.2020 16:14, Julien Grall wrote:
Hi Jan,

On 29/04/2020 15:05, Jan Beulich wrote:
On 29.04.2020 16:01, Julien Grall wrote:

On 22/04/2020 10:20, Jan Beulich wrote:
Even if it was possible to use the sub-structs defined in the header
that way, keep in mind that we also wrote:

           /* dummy member to force sizeof(struct xen_pvcalls_request)
            * to match across archs */
           struct xen_pvcalls_dummy {
               uint8_t dummy[56];
           } dummy;

This has nothing to do with how a consumer may use the structs.

And the spec also clarifies that the size of each specific request is
always 56 bytes.

Sure, and I didn't mean to imply that a consumer would be allowed
to break this requirement. Still something like this

int pvcall_new_socket(struct xen_pvcalls_socket *s) {
       struct xen_pvcalls_request req = {
           .req_id = REQ_ID,
           .cmd = PVCALLS_SOCKET,
           .u.socket = *s,

       return pvcall(&req);

may break.

I think I understand your concern now. So yes I agree this would break 32-bit 

As the padding is at the end of the structure, I think a 32-bit frontend and 
64-bit backend (or vice-versa) should currently work without any trouble. The 
problem would come later if we decide to extend a command.

Can commands be extended at all, i.e. don't extensions require new
commands? The issue I've described has nothing to do with future
extending of any of the affected structures.

I think my point wasn't conveyed correctly. The implicit padding is at
the end of the structure for all the consumers but 32-bit x86. So
without any modification, I think 32-bit frontend can still communicate
with 64-bit backend (or vice-versa).

There's no issue communicating afaics, as for communication
you wouldn't use the sub-structures, but the single container
one. The problem is, as described, with possible uses internal
to one side of the communication.

I am sorry but I can't figure out how this is an issue. The problem you described would only happen if you are calling a 64-bit library from a 32-bit software. Is it even possible?


Julien Grall



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