From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934232AbcA0QP1 (ORCPT ); Wed, 27 Jan 2016 11:15:27 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:42359 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754387AbcA0QPY (ORCPT ); Wed, 27 Jan 2016 11:15:24 -0500 Subject: Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest To: Konrad Rzeszutek Wilk 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> Cc: David Vrabel , "Luis R. Rodriguez" , Juergen Gross , Jeremy Fitzhardinge , Rusty Russell , Andrew Cooper , X86 ML , "linux-kernel@vger.kernel.org" , Andy Lutomirski , "H. Peter Anvin" , xen-devel@lists.xenproject.org, Borislav Petkov , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= From: Boris Ostrovsky Message-ID: <56A8ED0D.5030002@oracle.com> Date: Wed, 27 Jan 2016 11:15:09 -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: <20160127152950.GH552@char.us.oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: userv0022.oracle.com [156.151.31.74] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/27/2016 10:29 AM, Konrad Rzeszutek Wilk wrote: > 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 Yes, I saw that and this will be renamed as paravirt_legacy() (which I am not sure is really what it should be called.) Another option is to have early microcode code query CPUID to see whether we are running on a hypervisor (this in fact is what we originally thought of doing before realizing that we have paravirt_enabled()). But then how is HVMlite different from a regular HVM guest trying to load microcode? (BTW, to answer David's question about what KVM is doing --- it is ignoring writes to microcode MSRs, see kvm_set_msr_common().) -boris