From: Julien Grall <julien@xen.org>
To: Jan Beulich <jbeulich@suse.com>
Cc: Juergen Gross <jgross@suse.com>,
Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Julien Grall <jgrall@amazon.com>,
Ian Jackson <ian.jackson@eu.citrix.com>,
George Dunlap <george.dunlap@citrix.com>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH] pvcalls: Document explicitly the padding for all arches
Date: Mon, 20 Apr 2020 14:34:49 +0100 [thread overview]
Message-ID: <78288649-5930-9d01-bb8f-85e15406e4ef@xen.org> (raw)
In-Reply-To: <e07dbb22-1300-ae87-4065-824938caec48@suse.com>
Hi Jan,
On 20/04/2020 09:04, Jan Beulich wrote:
> On 19.04.2020 12:49, Julien Grall wrote:
>> --- a/docs/misc/pvcalls.pandoc
>> +++ b/docs/misc/pvcalls.pandoc
>> @@ -246,9 +246,7 @@ The format is defined as follows:
>> uint32_t domain;
>> uint32_t type;
>> uint32_t protocol;
>> - #ifdef CONFIG_X86_32
>> uint8_t pad[4];
>> - #endif
>> } socket;
>> struct xen_pvcalls_connect {
>> uint64_t id;
>> @@ -257,16 +255,12 @@ The format is defined as follows:
>> uint32_t flags;
>> grant_ref_t ref;
>> uint32_t evtchn;
>> - #ifdef CONFIG_X86_32
>> uint8_t pad[4];
>> - #endif
>> } connect;
>> struct xen_pvcalls_release {
>> uint64_t id;
>> uint8_t reuse;
>> - #ifdef CONFIG_X86_32
>> uint8_t pad[7];
>> - #endif
>> } release;
>> struct xen_pvcalls_bind {
>> uint64_t id;
>> @@ -276,9 +270,7 @@ The format is defined as follows:
>> struct xen_pvcalls_listen {
>> uint64_t id;
>> uint32_t backlog;
>> - #ifdef CONFIG_X86_32
>> uint8_t pad[4];
>> - #endif
>> } listen;
>> struct xen_pvcalls_accept {
>> uint64_t id;
>
> I wonder on what grounds these #ifdef-s had been there - they're
> plain wrong with the types used in the public header.
>
>> --- a/xen/include/public/io/pvcalls.h
>> +++ b/xen/include/public/io/pvcalls.h
>> @@ -65,6 +65,7 @@ struct xen_pvcalls_request {
>> uint32_t domain;
>> uint32_t type;
>> uint32_t protocol;
>> + uint8_t pad[4];
>> } socket;
>> struct xen_pvcalls_connect {
>> uint64_t id;
>> @@ -73,10 +74,12 @@ struct xen_pvcalls_request {
>> uint32_t flags;
>> grant_ref_t ref;
>> uint32_t evtchn;
>> + uint8_t pad[4];
>> } connect;
>> struct xen_pvcalls_release {
>> uint64_t id;
>> uint8_t reuse;
>> + uint8_t pad[7];
>> } release;
>> struct xen_pvcalls_bind {
>> uint64_t id;
>> @@ -86,6 +89,7 @@ struct xen_pvcalls_request {
>> struct xen_pvcalls_listen {
>> uint64_t id;
>> uint32_t backlog;
>> + uint8_t pad[4];
>> } listen;
>
> I'm afraid we can't change these in such a way - your additions
> change sizeof() for the respective sub-structures on 32-bit x86,
> and hence this is not a backwards compatible adjustment.
This is a bit confusing, each structure contain a 64-bit field so I
would have thought it the structure would be 8-byte aligned (as on
32-bit Arm). But looking at the spec, a uint64_t will only aligned to
4-byte.
However, I am not sure why sizeof() matters here. I understand the value
would be different, but AFAICT, this is not used as part of the protocol.
IIUC the request should always be 56-bytes, so at worse you will read
unknown bytes. Those bytes are at the end of the structure, so it should
not matter.
> The
> best I can think of right now that we could do is make the
> difference explicit, by putting the padding fields inside
> #ifndef __i386__. But of course this is awkward at least when
> thinking about a 32-bit / 64-bit pair of communication ends on
> an x86-64 host.
I don't think this is necessary because of the way a request has been
defined.
Cheers,
--
Julien Grall
next prev parent reply other threads:[~2020-04-20 13:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-19 10:49 [PATCH] pvcalls: Document explicitly the padding for all arches Julien Grall
2020-04-20 8:04 ` Jan Beulich
2020-04-20 13:34 ` Julien Grall [this message]
2020-04-20 13:45 ` Jan Beulich
2020-04-21 23:27 ` Stefano Stabellini
2020-04-22 9:20 ` Jan Beulich
2020-04-29 14:01 ` Julien Grall
2020-04-29 14:05 ` Jan Beulich
2020-04-29 14:14 ` Julien Grall
2020-04-29 14:56 ` Jan Beulich
2020-04-29 15:06 ` Julien Grall
2020-04-29 15:23 ` Jan Beulich
2020-04-29 15:30 ` Julien Grall
2020-04-29 15:57 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=78288649-5930-9d01-bb8f-85e15406e4ef@xen.org \
--to=julien@xen.org \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jbeulich@suse.com \
--cc=jgrall@amazon.com \
--cc=jgross@suse.com \
--cc=sstabellini@kernel.org \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).