[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] pvcalls: Document explicitly the padding for all arches
Hi Jan,
On 29/04/2020 16:23, Jan Beulich wrote:
On 29.04.2020 17:06, Julien Grall wrote:
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.
Why? The example given doesn't require such.
Your example is only valid if we change the padding. In my previous
e-mail I wrote "without modification" (i.e existing code) and marking
the implicit padding only for 64-bit x86 and Arm. So there is no change
in the size of the structure and therefore there is no issue to
recompile as the size would not change.
Is it even possible?
In principle yes, I think. I don't think OSes like Linux allow this,
though.
Do we really have to care about this?
Cheers,
--
Julien Grall
|
