Re: [PATCH] tools/libxc: Fix construction of HVM guests with non-default firmware

From: Ian Campbell <ian.campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Cc: "Wei Liu" <wei.liu2@citrix.com>,
	"Ian Jackson" <Ian.Jackson@eu.citrix.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [PATCH] tools/libxc: Fix construction of HVM guests with non-default firmware
Date: Thu, 12 Nov 2015 12:47:50 +0000	[thread overview]
Message-ID: <1447332470.18450.68.camel@citrix.com> (raw)
In-Reply-To: <5644880A.5030701@citrix.com>

On Thu, 2015-11-12 at 12:37 +0000, Andrew Cooper wrote:
> On 12/11/15 09:41, Ian Campbell wrote:
> > On Wed, 2015-11-11 at 20:18 +0000, Andrew Cooper wrote:
> > > c/s 1ee15d7 "libxl: switch HVM domain building to use xc_dom_*
> > > helpers"
> > > introduced a regression building HVM domains in combination with the
> > > libxl
> > > "firmware_override=" option.
> > > 
> > > The older HVM building code (now removed) had no 32bit ELF check, so
> > > would
> > > happily load ELF64 images which contained a stub to switch into long
> > > mode.
> > IOW a ELF64 with 32-bit code at its entry point? Is that entry point
> > the
> > ELF entry point or the special Xen entry point located via the notes?
> > 
> > I think you likely mean the latter, in which case I'm ok with this
> > change
> > if that entry point is explicitly documented to be 32-bit irrespective
> > of
> > the containing ELF file (either the commit message should mention this
> > is 
> > already the case or the patch should update the docs to make it so).
> 
> I mean the former.  This has nothing to do with DMLite guests, so no
> elfnotes are involved.
> 
> I realise that strictly speaking the elf check should match.  However,
> it always used to work, and is sufficiently convenient for development
> purposes that I feel the check is more problematic than helpful. 
> (Postprocessing the linked binary from 64bit to 32bit elf is an extra
> step which also makes it harder to disassemble.)

An ELF file which says it is class ELF32 but has 64bit code at the entry
point is IMHO malformed.

I think that the fact this used to work is a misfeature, however convenient
you may have found it.

Kernels which wish to do this should IMHO do as Xen does and have a
mkelf32.c step. You can still run gdb or whatever using the original ELF
file.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel