Jimi Xenidis
2007-Jan-04 17:51 UTC
Re: [Fwd: Re: [Xen-devel] [ANNOUNCE] Xen 3.0.4 release candidate 2]
*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@xensource.com> > Date: December 18, 2006 11:31:37 AM EST > To: Magnus Damm <magnus.damm@gmail.com> > Cc: Keir Fraser <keir@xensource.com>, xen-devel <xen- > devel@lists.xensource.com>, Horms <horms@verge.net.au>, > Hollis Blanchard <hollisb@us.ibm.com> > 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@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Jan-04 17:58 UTC
Re: [Fwd: Re: [Xen-devel] [ANNOUNCE] Xen 3.0.4 release candidate 2]
On 4/1/07 17:51, "Jimi Xenidis" <jimix@watson.ibm.com> wrote:> 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.This one slipped through the net. We¹ll get rid of the need for packed in this case (in fact we¹ll remove the structs entirely!) before 3.0.5. In fact, as soon as Ian Campbell has time to fix it properly. :-) -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Magnus Damm
2007-Jan-05 02:58 UTC
Re: [Fwd: Re: [Xen-devel] [ANNOUNCE] Xen 3.0.4 release candidate 2]
On 1/5/07, Jimi Xenidis <jimix@watson.ibm.com> wrote:> 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.crash_notes in xen/common/kexec.c needs to be PACKED because existing tools expect the notes to be aligned in a certain way. Regardless if your architecture supports unaligned accesses or not. This 32-bit-elf-note-alignment-on-64-bit-platforms doesn''t make sense at all, but we need to follow the already adapted format or things won''t work. See this thread for more information: http://lkml.org/lkml/2006/11/2/69 The current kexec-for-dom0 implementation works for i386 and x86_64, but it is likely broken for architectures that doesn''t support unaligned accesses. The right solution IMO is to keep crash_notes PACKED but do all accesses through a local copy of the structure and then update crash_notes through a memcpy(). / magnus _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel