From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757134AbcBDW2K (ORCPT ); Thu, 4 Feb 2016 17:28:10 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:44588 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753178AbcBDW2J (ORCPT ); Thu, 4 Feb 2016 17:28:09 -0500 Subject: Re: [PATCH v2 02/11] xen/hvmlite: Bootstrap HVMlite guest To: "Luis R. Rodriguez" 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> Cc: "Luis R. Rodriguez" , David Vrabel , konrad.wilk@oracle.com, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, roger.pau@citrix.com, x86@kernel.org, GLin@suse.coma, bblanco@plumgrid.com, pmonclus@plumgrid.com, bp@suse.de, hpa@zytor.com From: Boris Ostrovsky Message-ID: <56B3D070.9000607@oracle.com> Date: Thu, 4 Feb 2016 17:28:00 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20160204205721.GJ12481@wotan.suse.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: userv0021.oracle.com [156.151.31.71] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.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