From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest Date: Wed, 27 Jan 2016 14:50:36 +0000 Message-ID: <56A8D93C.6040304__28890.862214803$1453906349$gmane$org@citrix.com> References: <56A2C99A.2050701@citrix.com> <56A39300.8050802@citrix.com> <20160125221920.GG20964@wotan.suse.de> <56A6A7C6.8060906@oracle.com> <20160126203023.GI20964@wotan.suse.de> <56A7EA6A.2030502@oracle.com> <20160127000435.GK20964@wotan.suse.de> <20160127144240.GB552@char.us.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 1aORQm-0001yX-OR for xen-devel@lists.xenproject.org; Wed, 27 Jan 2016 14:50:48 +0000 In-Reply-To: <20160127144240.GB552@char.us.oracle.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Konrad Rzeszutek Wilk , "Luis R. Rodriguez" Cc: Juergen Gross , Jeremy Fitzhardinge , X86 ML , Andrew Cooper , Rusty Russell , "linux-kernel@vger.kernel.org" , Andy Lutomirski , "H. Peter Anvin" , xen-devel@lists.xenproject.org, Boris Ostrovsky , Borislav Petkov , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= List-Id: xen-devel@lists.xenproject.org On 27/01/16 14:42, Konrad Rzeszutek Wilk wrote: > On Tue, Jan 26, 2016 at 08:54:56PM -0800, Luis R. Rodriguez wrote: >> On Jan 26, 2016 6:16 PM, "Luis R. Rodriguez" wrote: >>> >>> On Tue, Jan 26, 2016 at 4:04 PM, Luis R. Rodriguez >> wrote: >>>> You go: >>>> >>>> hvmlite_start_xen() --> >>>> HVM stub >>>> startup_64() | (startup_32() >>> >>> Hrm, does HVMlite work well with load_ucode_bsp(), note the patches to >>> rebrand pv_enabled() to pv_legacy() or whatever, this PV type will not >>> be legacy or crap / old, so we'd need a way to catch it if we should >>> not use that code for this PV type. This begs the question, are you >>> also sure other callers in startup_32() or startup_64() might be OK as >>> well where previously guarded with pv_enabled() ? >> >> Actually this call can't be used, and if early code used it prior to >> setup_arch() it'd be a bug as its only properly set until later. Vetting >> for correctness of all code call is still required though and perhaps we do >> need something to catch now this PV type on early code such as this one if >> we don't want it. From what I've gathered before on other bsp ucode we >> don't want ucode loaded for PV guest types through these mechanisms. > > It may help to not think of PVH/hvmlite as PV. It really is HVM with a lot > of emulated devices removed. > > How does early microcode work on EFI? Does the EFI stub code have an early > microcode loading code ? Surely the interesting comparison here is how is (early) microcode loading disabled in KVM guests? We should use the same mechanism for HVMlite guests. David