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

[Jan Beulich <jbeulich@xxxxxxxx>]

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:
>>> Hi,
>>>
>>> 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 consumer.
>>>
>>> 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.

Jan