From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752008AbcAZTA3 (ORCPT ); Tue, 26 Jan 2016 14:00:29 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:51859 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751982AbcAZTAZ (ORCPT ); Tue, 26 Jan 2016 14:00:25 -0500 Subject: Re: [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest To: Andy Lutomirski , "Luis R. Rodriguez" References: <1453498558-6028-1-git-send-email-boris.ostrovsky@oracle.com> <1453498558-6028-5-git-send-email-boris.ostrovsky@oracle.com> <20160122233218.GA20964@wotan.suse.de> <56A6488F.5030909@oracle.com> <20160125211203.GF20964@wotan.suse.de> <56A691F0.6020404@zytor.com> <56A6A178.9020200@oracle.com> <20160126183425.GH20964@wotan.suse.de> Cc: "H. Peter Anvin" , David Vrabel , Konrad Rzeszutek Wilk , "xen-devel@lists.xenproject.org" , "linux-kernel@vger.kernel.org" , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Juergen Gross , Rusty Russell , Borislav Petkov , Jeremy Fitzhardinge From: Boris Ostrovsky Message-ID: <56A7C239.4060107@oracle.com> Date: Tue, 26 Jan 2016 14:00:09 -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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: userv0022.oracle.com [156.151.31.74] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/26/2016 01:46 PM, Andy Lutomirski wrote: > On Tue, Jan 26, 2016 at 10:34 AM, Luis R. Rodriguez wrote: >> On Mon, Jan 25, 2016 at 05:28:08PM -0500, Boris Ostrovsky wrote: >>> On 01/25/2016 04:21 PM, H. Peter Anvin wrote: >>>> On 01/25/16 13:12, Luis R. Rodriguez wrote: >>>>>> Perhaps, but someone would still have to set hardware_subarch. And >>>>>> it's hvmlite_bootparams() that does it. >>>>> No, Xen would do it as well, essentially all of hvmlite_bootparams() could be >>>>> done in Xen. >>>>> >>>> Or a stub code. >>> This patch in fact is the stub for Xen HVMlite guests, after we are >>> done with it we jump to bare-metal startup code (i.e startup_32|64) >> Right the point is the stub need not be in Linux, I'll explain in the other >> thread where I provided more details on the different known approaches. >> > ISTM if the Xen ABI-specified entry point has a different convention > than the Linux native entry, then the stub should live in Linux. It > would be just a couple if lines of code, right? It's not exactly a couple of lines but it's not large neither. It mainly sets up boot_params (similar to what make_boot_params() does for EFI). Plus, for 64-bit, it loads identity page tables and switches to long mode. And then jumps to bare-meta startup code. > > The issue that caused headaches in the past isn't that there's code > that's executed only on native, it's that there are whole big > functions that are executed only on native for no good reason and that > aren't clearly marked. This won't happen with HVMlite. > > If we had native_start_kernel and xen_start_kernel, and they both > called very quickly in to common_start_kernel, it would be very clear > what's going on. What is now xen_start_kernel() is no longer the entry point for HVMlite. It is called as x86_init.oem.arch_setup() (or I may even move it to x86_hyper_xen.init_platform() or something like that). -boris