Re: [Fwd: Re: [Xen-devel] [ANNOUNCE] Xen 3.0.4 release candidate 2]

[Jimi Xenidis <jimix@xxxxxxxxxxxxxx>]

*sigh*

IIRC the maintainers all agreed that common code would not contain packed data structures.  To keep everyone honest we suggested that the common dir be build with -Wpacked however there were packed x86 structs that were sucked in "uncommon" common code :(, so we wnabled it in the PPc build only.

This is a problem for all RISC architectures and arguably a performance for all since it risks unaligned storage access.  Micro-coding issues aside, the most pathological case being that the word straddles a page boundary and we get an actual alignment interrupt which a correctly designed program should simply never get.

IMNSHO the fact that these structures require PACKED is a clear indication that the dizzying array of macro-itis in include/xen/elfcore.h and friends has issues.

Letting it "slip by", especially for a release, means that to fix the data structure will break compatibility with the release.

Question to all is, should we make an attempt at fixing the data structure or should we go back to a PACKED macro that is empty for arches that that do not wish to support it.

-JX

On Jan 2, 2007, at 2:40 PM, Hollis Blanchard wrote:

Did you see this thread? -Wpacked is your pet peeve, not mine... :)

-- 

Hollis Blanchard

IBM Linux Technology Center

From: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>

Date: December 18, 2006 11:31:37 AM EST

To: Magnus Damm <magnus.damm@xxxxxxxxx>

Cc: Keir Fraser <keir@xxxxxxxxxxxxx>,        xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Horms <horms@xxxxxxxxxxxx>,        Hollis Blanchard <hollisb@xxxxxxxxxx>

Subject: Re: [Xen-devel] [ANNOUNCE] Xen 3.0.4 release candidate 2

On Mon, 2006-12-18 at 21:48 +0900, Magnus Damm wrote:

The ELF notes for kexec / kdump are screwed up on x86_64.

That was due to 12977:af39d20b2b728941421ef18e5c5b1012852eec80[0] which

I have now reverted. The reversion will be

13080:4ef0dbe95eac33033abeee36a8f13eaaeb9d5639 once it comes through

regression testing.

Hollis, what was the warning the change was introduced to avoid? If you

have any ideas for another workaround for them in the 3.0.4 release we'd

be grateful to hear it ASAP -- Keir plans to roll the final RC in the

next 24 hours.

Cheers,

Ian.

[0] http://xenbits2.xensource.com/xen-unstable.hg?cs=12977

$ readelf -a vmcore-3.0.4-rc2-x86_64

[snip]

Notes at offset 0x00000120 with length 0x000002c8:

  Owner         Data size       Description

  CORE          0x00000150      NT_PRSTATUS (prstatus structure)

  CORE          0x00000150      NT_PRSTATUS (prstatus structure)

$ readelf -a vmcore-3.0.4-rc1-x86_64

[snip]

Notes at offset 0x00000120 with length 0x00000380:

  Owner         Data size       Description

  CORE          0x00000150      NT_PRSTATUS (prstatus structure)

  Xen           0x00000020      Unknown note type: (0x01000002)

  CORE          0x00000150      NT_PRSTATUS (prstatus structure)

  Xen           0x00000020      Unknown note type: (0x01000002)

  Xen           0x00000048      Unknown note type: (0x01000001)

x86_32 seems to work as expected though.

/ magnus

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel