From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935324AbcA0X7L (ORCPT ); Wed, 27 Jan 2016 18:59:11 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:28699 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933397AbcA0X7J (ORCPT ); Wed, 27 Jan 2016 18:59:09 -0500 Subject: Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest To: "Luis R. Rodriguez" , Takashi Iwai , Avi Kivity , Joerg Roedel , "H. Peter Anvin" , Borislav Petkov , Konrad Rzeszutek Wilk , Andy Lutomirski , Andrew Cooper References: <20160126203023.GI20964@wotan.suse.de> <56A7EA6A.2030502@oracle.com> <20160127000435.GK20964@wotan.suse.de> <20160127144240.GB552@char.us.oracle.com> <56A8D93C.6040304@citrix.com> <56A8DCFD.6040603@oracle.com> <56A8DDAA.1010205@citrix.com> <56A8DFA4.5000801@oracle.com> <20160127152950.GH552@char.us.oracle.com> <56A8ED0D.5030002@oracle.com> Cc: David Vrabel , Juergen Gross , Jeremy Fitzhardinge , Rusty Russell , X86 ML , "linux-kernel@vger.kernel.org" , xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= From: Boris Ostrovsky Message-ID: <56A959C0.70103@oracle.com> Date: Wed, 27 Jan 2016 18:58:56 -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: aserv0022.oracle.com [141.146.126.234] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/27/2016 02:00 PM, Luis R. Rodriguez wrote: > On Wed, Jan 27, 2016 at 10:48 AM, Luis R. Rodriguez wrote: >> Worth mentioning here also is hpa's clarification on when subarch type >> PC (0) should be used: [it should be used if the hardware is] >> "enumerable using standard PC mechanisms (PCI, ACPI) and doesn't need >> a special boot flow" -- does that fit HVMLite's description so far? If >> so then The Xen subarch may need to be redefined as well to be clear >> what it means. I don't think we need to be precise but at the very >> least cover grounds to enable the definitions to meet its actual use >> to not confuse users. > Another thing to consider for HVMlite is that if the 0 subarch (PC) is > used in light of my linker table work and x86's use of it with the > subarch and supported subarch bitmask, is that it would also mean > HVMLite would run all routines currently pegged as needing PC type > (the current KVM and bare metal path) and it would mean not running > anything only pegged with Xen subarch type (but note that today Xen > doesn't even set the subarch type). If there is nothing in common > between PV and HVMlite (no x86 init calls to share), and if HVMLite > *can* call *alllllllll* PC init calls, then by all means this is fine, Yes, that's the idea. HVMlite jumps to startup_32|64 from the stub and runs from there with subarch 0. -boris > and if we just need to distinguish stuff between PC types that's fine, > it may still be possible to further extend hypervisor_type to the x86 > init calls I'm adding as another supported_hyper_types to ensure even > though a subarch is being used, that we also check the supported > hypervisor type as well. > > Luis