From: Julien Grall <firstname.lastname@example.org> To: Jan Beulich <email@example.com> Cc: Andrew Cooper <firstname.lastname@example.org>, George Dunlap <George.Dunlap@eu.citrix.com>, Ian Jackson <email@example.com>, Wei Liu <firstname.lastname@example.org>, Stefano Stabellini <email@example.com>, "firstname.lastname@example.org" <email@example.com> Subject: Re: [PATCH v3] evtchn/fifo: don't enforce higher than necessary alignment Date: Thu, 29 Apr 2021 12:55:31 +0100 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> Hi Jan, On 22/04/2021 10:19, Jan Beulich wrote: > On 21.04.2021 21:52, Julien Grall wrote: >> Hi, >> >> On 21/04/2021 15:36, Jan Beulich wrote: >>> Neither the code nor the original commit provide any justification for >>> the need to 8-byte align the struct in all cases. Enforce just as much >>> alignment as the structure actually needs - 4 bytes - by using alignof() >>> instead of a literal number. >> >> I had another fresh look today at this patch. The 32-bit padding is >> right after the field 'ready'. >> >> I can't for sure tell how the second half is going to ever be used and how. >> >> However, one possibility would be to extend the field 'ready' to 64-bit. >> With the current code, we could easily make a single 64-bit access >> without having to know whether the guest is able to interpret the top half. > > I don't think extending field sizes is generally to be considered ABI- > compatible. I also don't think we can re-use the field at all, as I > couldn't find any checking of it being zero (input) or it getting set > to zero (output). That's would be fine so long we have a flag to control it. We can still write unconditionally because a guest can't rely on the pad... > struct evtchn_init_control, which in principle could > be a way to convey respective controlling flags, similarly has no room > for extension, as its _pad also doesn't look to get checked anywhere. Right, we would need to have a different way to convey. Yet, I am still unconvinced of the benefits change offer in this patch. I am not going to Nack. So another maintainer in "THE REST" can express support for your patch and ack it. Cheers, -- Julien Grall
prev parent reply other threads:[~2021-04-29 11:55 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-12-22 8:13 [PATCH v2 0/2] common: XSA-327 follow-up Jan Beulich 2020-12-22 8:14 ` [PATCH v2 1/2] common: map_vcpu_info() cosmetics Jan Beulich 2021-04-01 16:02 ` Julien Grall 2020-12-22 8:15 ` [PATCH v2 2/2] evtchn/fifo: don't enforce higher than necessary alignment Jan Beulich 2021-04-21 14:36 ` [PATCH v3] " Jan Beulich 2021-04-21 19:52 ` Julien Grall 2021-04-22 9:19 ` Jan Beulich 2021-04-29 11:55 ` Julien Grall [this message]
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 \ --firstname.lastname@example.org \ --email@example.com \ --cc=George.Dunlap@eu.citrix.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH v3] evtchn/fifo: don'\''t enforce higher than necessary alignment' \ /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
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).