From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Luis R. Rodriguez" Subject: Re: [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest Date: Wed, 27 Jan 2016 11:00:36 -0800 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aOVPo-00036S-1c for xen-devel@lists.xenproject.org; Wed, 27 Jan 2016 19:06:04 +0000 Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 215C920380 for ; Wed, 27 Jan 2016 19:00:59 +0000 (UTC) Received: from mail-yk0-f179.google.com (mail-yk0-f179.google.com [209.85.160.179]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 514E120373 for ; Wed, 27 Jan 2016 19:00:57 +0000 (UTC) Received: by mail-yk0-f179.google.com with SMTP id y137so2651350yka.2 for ; Wed, 27 Jan 2016 11:00:57 -0800 (PST) In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Boris Ostrovsky , Takashi Iwai , Avi Kivity , Joerg Roedel , "H. Peter Anvin" , Borislav Petkov , Konrad Rzeszutek Wilk , Andy Lutomirski , Andrew Cooper Cc: Juergen Gross , Jeremy Fitzhardinge , Rusty Russell , X86 ML , "linux-kernel@vger.kernel.org" , "Luis R. Rodriguez" , David Vrabel , xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= List-Id: xen-devel@lists.xenproject.org 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, 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