qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/7] Fix packing for MinGW with -mms-bitfields


From: Stefan Weil
Subject: Re: [Qemu-devel] [PATCH 0/7] Fix packing for MinGW with -mms-bitfields
Date: Tue, 30 Aug 2011 19:25:32 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Iceowl/1.0b1 Icedove/3.0.11

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 <address@hidden> wrote:
Am 28.08.2011 23:43, schrieb Blue Swirl:

On Sun, Aug 28, 2011 at 8:43 PM, Stefan Weil <address@hidden>
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.

Cheers,
Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]