On 07.09.2020 11:20, Roger Pau Monné wrote: > On Mon, Sep 07, 2020 at 10:21:36AM +0200, Jan Beulich wrote: >> On 07.09.2020 00:48, osstest service owner wrote: >>> branch xen-unstable >>> xenbranch xen-unstable >>> job test-amd64-i386-xl-shadow >>> testid guest-saverestore >>> >>> Tree: linux git://xenbits.xen.org/linux-pvops.git >>> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git >>> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git >>> Tree: qemuu git://xenbits.xen.org/qemu-xen.git >>> Tree: xen git://xenbits.xen.org/xen.git >>> >>> *** Found and reproduced problem changeset *** >>> >>> Bug is in tree: xen git://xenbits.xen.org/xen.git >>> Bug introduced: 696c273f3d9a169911308fb7e0a702a3eb6a150d >>> Bug not present: a609b6577f7867db4be1470130b7b3c686398c4f >>> Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/153833/ >>> >>> >>> commit 696c273f3d9a169911308fb7e0a702a3eb6a150d >>> Author: Jan Beulich <jbeul...@suse.com> >>> Date: Fri Sep 4 11:13:01 2020 +0200 >>> >>> x86: generalize padding field handling >>> >>> The original intention was to ignore padding fields, but the pattern >>> matched only ones whose names started with an underscore. Also match >>> fields whose names are in line with the C spec by not having a leading >>> underscore. (Note that the leading ^ in the sed regexps was pointless >>> and hence get dropped.) >> >> I conclude this needs to be reverted, and there was a thinko of mine >> involved here: Avoiding translation of padding fields would be okay >> only when their values don't get checked in the native handler. We >> effectively have a not written down (afaict) rule here that _pad* >> fields get ignored (and hence don't need translation), while pad* >> fields may not be ignored and hence may need translation. I don't >> like this state, but I also can't think of a good way out of it, at >> least not just yet. > > I think his stems from the fact that we don't have a rule whether > explicit padding fields in structs should be zeroed. IIRC there are > hypercalls that would check for padding fields to be 0, while others > don't.
Right - we only have an almost-rule for new code. > At this point I assume we can only implement the least restrictive > one, which is to not force padding fields to be zeroed? Well, we could formalize the (or ideally: some) naming model to distinguish the cases. Question then is going to be in how many cases neither contributor nor reviewers are(n't) going to pay attention. > This would have the side effect that they cannot be later used to > introduce additional fields to the struct without signaling the > version in use. Exactly, so unilaterally going the "don't copy and hence don't require zero" route is not an option imo. Jan
