[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: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. 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? Cheers, -- Julien Grall
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |