[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 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.




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