From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest Date: Wed, 27 Jan 2016 10:29:50 -0500 Message-ID: <20160127152950.GH552@char.us.oracle.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aOS3D-0007MF-Dc for xen-devel@lists.xenproject.org; Wed, 27 Jan 2016 15:30:31 +0000 Content-Disposition: inline In-Reply-To: <56A8DFA4.5000801@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: Boris Ostrovsky Cc: Juergen Gross , Jeremy Fitzhardinge , "Luis R. Rodriguez" , Andrew Cooper , Rusty Russell , X86 ML , "linux-kernel@vger.kernel.org" , Borislav Petkov , David Vrabel , "H. Peter Anvin" , xen-devel@lists.xenproject.org, Andy Lutomirski , Roger Pau =?iso-8859-1?Q?Monn=E9?= List-Id: xen-devel@lists.xenproject.org On Wed, Jan 27, 2016 at 10:17:56AM -0500, Boris Ostrovsky wrote: > On 01/27/2016 10:09 AM, David Vrabel wrote: > >On 27/01/16 15:06, Boris Ostrovsky wrote: > >>On 01/27/2016 09:50 AM, David Vrabel wrote: > >>>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. > >> > >>Why would we ever want to have a guest load microcode during boot? I can > >>see how a (privileged) guest may want to load microcode from a shell > >>(via microcode driver). > >I think you missed a word when you read my reply. > > Yes, I missed it ;-) > > Why not continue relying on paravirt_enabled()? We are going to keep this in > some form for HVMlite. And this is where Luis comes in. He has posted an patchset which removes the paravirt_enabled with .. Here is the link https://lkml.org/lkml/2015/12/15/772