From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH] tools/libxc: Fix construction of HVM guests
 with non-default firmware
Date: Thu, 12 Nov 2015 12:37:30 +0000
Message-ID: <5644880A.5030701@citrix.com>
References: <1447273084-15265-1-git-send-email-andrew.cooper3@citrix.com>
	<1447321286.18450.40.camel@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <1447321286.18450.40.camel@citrix.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Ian Campbell <ian.campbell@citrix.com>, Xen-devel <xen-devel@lists.xen.org>
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= <roger.pau@citrix.com>
List-Id: xen-devel@lists.xenproject.org

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.)

~Andrew