From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933478AbcA0PJf (ORCPT ); Wed, 27 Jan 2016 10:09:35 -0500 Received: from smtp.citrix.com ([66.165.176.89]:6654 "EHLO SMTP.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932737AbcA0PJe (ORCPT ); Wed, 27 Jan 2016 10:09:34 -0500 X-IronPort-AV: E=Sophos;i="5.22,354,1449532800"; d="scan'208";a="327976505" Subject: Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest To: Boris Ostrovsky , Konrad Rzeszutek Wilk , "Luis R. Rodriguez" 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> <56A8D93C.6040304@citrix.com> <56A8DCFD.6040603@oracle.com> CC: Juergen Gross , Jeremy Fitzhardinge , Rusty Russell , Andrew Cooper , X86 ML , "linux-kernel@vger.kernel.org" , "Andy Lutomirski" , "H. Peter Anvin" , , Borislav Petkov , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= From: David Vrabel Message-ID: <56A8DDAA.1010205@citrix.com> Date: Wed, 27 Jan 2016 15:09:30 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0 MIME-Version: 1.0 In-Reply-To: <56A8DCFD.6040603@oracle.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-DLP: MIA2 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. David