From mboxrd@z Thu Jan  1 00:00:00 1970
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [PATCH v2 02/11] xen/hvmlite: Bootstrap HVMlite
	guest
Date: Thu, 4 Feb 2016 17:28:00 -0500
Message-ID: <56B3D070.9000607__6694.70228390328$1454624958$gmane$org@oracle.com>
References: <1454341137-14110-1-git-send-email-boris.ostrovsky@oracle.com>
	<1454341137-14110-3-git-send-email-boris.ostrovsky@oracle.com>
	<20160203185525.GV20964@wotan.suse.de> <56B25F0C.2050808@oracle.com>
	<20160203234026.GS20964@wotan.suse.de> <56B3AC67.7080704@oracle.com>
	<20160204205721.GJ12481@wotan.suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <boris.ostrovsky@oracle.com>) id 1aRSNc-0007uq-Vx
	for xen-devel@lists.xenproject.org; Thu, 04 Feb 2016 22:28:01 +0000
In-Reply-To: <20160204205721.GJ12481@wotan.suse.de>
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: "Luis R. Rodriguez" <mcgrof@suse.com>
Cc: pmonclus@plumgrid.com, GLin@suse.coma, bblanco@plumgrid.com, x86@kernel.org, linux-kernel@vger.kernel.org, "Luis R. Rodriguez" <mcgrof@kernel.org>, David Vrabel <david.vrabel@citrix.com>, hpa@zytor.com, xen-devel@lists.xenproject.org, bp@suse.de, roger.pau@citrix.com
List-Id: xen-devel@lists.xenproject.org

On 02/04/2016 03:57 PM, Luis R. Rodriguez wrote:
>
> Ah, well here lies the issue. As per hpa subarch was not designed for defining
> a hypervisor, but rather at least subarch PC (0) [should be used if the
> hardware is] "enumerable using standard PC mechanisms (PCI, ACPI) and doesn't
> need a special boot flow". Does that follow the definition of HVMlite?

Yes. HVMlite is going to use baremetal boot flow.

> OK great. That still means the code will run, and if we can avoid that
> why not. I am fine with annotating this as future work to help. Let me
> then ask as well, how about the rest of the code during and after
> startup_32() and startup_64() -- are we sure that's all safe ?

I can't be sure, all I can say is that so far I haven't seen any problems.

-boris