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

Jan



 


Rackspace

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