qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Alexander Graf <agraf@suse.de>
Cc: Isaku Yamahata <yamahata@valinux.co.jp>,
	TeLeMan <geleman@gmail.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Blue Swirl <blauwirbel@gmail.com>, Jan Kiszka <jan.kiszka@web.de>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Aurelien Jarno <aurel@aurel32.net>
Subject: Re: [Qemu-devel] [PATCH 0/7] Fix packing for MinGW with -mms-bitfields
Date: Wed, 31 Aug 2011 09:40:13 +0200	[thread overview]
Message-ID: <4E5DE55D.3070501@redhat.com> (raw)
In-Reply-To: <731DACCB-4F4A-4213-B7EC-2AB1D6989B08@suse.de>

Am 30.08.2011 20:29, schrieb Alexander Graf:
> 
> On 30.08.2011, at 19:25, Stefan Weil wrote:
> 
>> Am 30.08.2011 09:44, schrieb Kevin Wolf:
>>> Am 29.08.2011 21:55, schrieb Stefan Weil:
>>>> Am 29.08.2011 10:34, schrieb TeLeMan:
>>>>> On Mon, Aug 29, 2011 at 13:01, Stefan Weil <weil@mail.berlios.de> wrote:
>>>>>> Am 28.08.2011 23:43, schrieb Blue Swirl:
>>>>>>>
>>>>>>> On Sun, Aug 28, 2011 at 8:43 PM, Stefan Weil <weil@mail.berlios.de>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> These patches fix the packing of structures which were affected by
>>>>>>>> the new compiler attribute -mms-bitfields (which is needed for
>>>>>>>> glib-2.0).
>>>>>>>>
>>>>>>>> I compiled qemu.exe with and without -mms-bitfields and compared
>>>>>>>> the resulting struct alignment using pahole and codiff.
>>>>>>>
>>>>>>> If a structure is only used internally by QEMU (not used in network,
>>>>>>> disk or guest interfaces), changes in padding don't matter. In fact,
>>>>>>> in those cases it may be better to remove the packing, because then
>>>>>>> the fields may be naturally aligned and that gives better performance
>>>>>>> on most architectures. Could you please check if this is the case for
>>>>>>> any of the structs?
>>>>>>
>>>>>> I did this already, but also forward your question to the maintainers.
>>>>>> Here is my result:
>>>>>>
>>>>>> [PATCH 2/7] block/vvfat: Fix packing for w32: needs packing (disk)
>>>>>> [PATCH 3/7] acpi: Fix packing for w32: needs packing (bios interface)
>>>>>> [PATCH 4/7] hpet: Fix packing for w32: needs packing (bios interface)
>>>>>> [PATCH 5/7] usb: Fix packing for w32: needs packing (usb interface)
>>>>>> [PATCH 6/7] virtio: Fix packing for w32: needs packing? (guest
>>>>>> interface?)
>>>>>> [PATCH 7/7] slirp: Fix packing for w32: needs packing (network interface)
>>>>>>
>>>>>> All those struct statements need the pack attribute (otherwise the code
>>>>>> would have to be rewritten which is of course always possible).
>>>>> gesn_cdb in atapi.c, VMDK4Header in vmdk.c and many structures in
>>>>> bt.h need be fixed too.
>>>>
>>>> Oops, you are right. Obviously I missed all anonymous structs:
>>>> codiff simply ignores them, and pahole must be called with
>>>> flags -a -A to show them. Who invented packing of structs?
>>>>
>>>> Comparing the output of pahole -a -A is less elegant than using
>>>> codiff, but shows the structs which you mentioned.
>>>>
>>>> I suggest to apply my patch series first because it fixes
>>>> the most important bugs in networking. The remaining
>>>> bugs are in code which is used less often. They will be
>>>> fixed by a second patch series which replaces all remaining
>>>> packed attributes.
>>>
>>> Shouldn't we have a look at every packed structure instead of just
>>> fixing what we notice as broken in the x86 emulator binary with one
>>> given configuration? I think if there is a QEMU_PACKED, we should use it
>>> consistently, or is there a reason not to do so?
>>>
>>> Kevin
>>
>> Hi Kevin,
>>
>> yes, we should use QEMU_PACKED instead of any __attribute__((packed)).
>>
>> The first 7 patches simply introduce QEMU_PACKED
>> and fix the most important bugs for those users who run
>> QEMU on Windows. There was only a bug report for broken
>> networking (fixed by Jan's committed patch and the above
>> slirp patch). These fixes work for all targets, so
>> chances are good that Windows users will have
>> working binaries for the commonly used scenarios with
>> any target - although I only examined qemu.exe.
>>
>> For this reason, these patches should be applied to git
>> master as soon as possible.
>>
>> I did not intend to have a look at every packed structure
>> as was suggested by Alex, Blue and others.
>> I simply wanted to run a global replace (perl -pi -e ...)
>> which replaced the remaining __attributes__.
>>
>> Reviewing every __attribute__ takes much more time of course:
>> there are more than 250 of them.
>> I don't think that a review is really necessary, because usually
>> "packed" is not added just for fun, and most QEMU code
>> was already reviewed. A small rate of unnecessary QEMU_PACKED
>> would do no harm, because only performance suffers a little.
>>
>> If more people agreed that QEMU_PACKED can be introduced
>> mechanically by a script without a new review, I could send
>> a patch very soon.
> 
> I think that's the better approach to the partial commit. Just introduce QEMU_PACKED, provide the script/sed cmdline you ran over the tree and replace it in every file. That makes more sense to commit than the partial conversion.
> 
> But please wait for a second opinion here :)

I agree.

Kevin

  parent reply	other threads:[~2011-08-31  7:37 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-28 20:43 [Qemu-devel] [PATCH 0/7] Fix packing for MinGW with -mms-bitfields Stefan Weil
2011-08-28 20:43 ` [Qemu-devel] [PATCH 1/7] Add new macro QEMU_PACKED for packed C structures Stefan Weil
2011-08-28 20:47   ` Andreas Färber
2011-08-29  5:12     ` Stefan Weil
2011-08-30 17:57   ` Blue Swirl
2011-08-30 18:29     ` Paolo Bonzini
2011-08-30 20:17       ` Stefan Weil
2011-08-28 20:43 ` [Qemu-devel] [PATCH 2/7] block/vvfat: Fix packing for w32 Stefan Weil
2011-08-29  8:09   ` Kevin Wolf
2011-08-28 20:43 ` [Qemu-devel] [PATCH 3/7] acpi: " Stefan Weil
2011-08-28 20:43 ` [Qemu-devel] [PATCH 4/7] hpet: " Stefan Weil
2011-08-28 20:43 ` [Qemu-devel] [PATCH 5/7] usb: " Stefan Weil
2011-08-28 20:43 ` [Qemu-devel] [PATCH 6/7] virtio: " Stefan Weil
2011-08-28 20:43 ` [Qemu-devel] [PATCH 7/7] slirp: " Stefan Weil
2011-08-29 10:12   ` Jan Kiszka
2011-08-29 18:22     ` Stefan Weil
2011-08-29 21:15       ` Jan Kiszka
2011-08-28 21:43 ` [Qemu-devel] [PATCH 0/7] Fix packing for MinGW with -mms-bitfields Blue Swirl
2011-08-29  5:01   ` Stefan Weil
2011-08-29  7:19     ` Gerd Hoffmann
2011-08-29  8:34     ` TeLeMan
2011-08-29  9:39       ` Alexander Graf
2011-08-29 19:55       ` Stefan Weil
2011-08-30  7:44         ` Kevin Wolf
2011-08-30 17:25           ` Stefan Weil
2011-08-30 18:29             ` Alexander Graf
2011-08-30 19:57               ` Blue Swirl
2011-08-31  7:40               ` Kevin Wolf [this message]
2011-08-31 10:37                 ` [Qemu-devel] [PATCH 0/2] Fix packing for MinGW with new macro QEMU_PACKED Stefan Weil
2011-09-03 21:12                   ` Blue Swirl
2011-08-31 10:38                 ` [Qemu-devel] [PATCH 1/2] Add new macro QEMU_PACKED for packed C structures Stefan Weil
2011-08-31 10:38                 ` [Qemu-devel] [PATCH 2/2] Use new macro QEMU_PACKED for packed structures Stefan Weil

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=4E5DE55D.3070501@redhat.com \
    --to=kwolf@redhat.com \
    --cc=agraf@suse.de \
    --cc=aurel@aurel32.net \
    --cc=blauwirbel@gmail.com \
    --cc=geleman@gmail.com \
    --cc=jan.kiszka@web.de \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=yamahata@valinux.co.jp \
    /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).