Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

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" <mcgrof@suse.com> wrote:
>>>>>>>> On Tue, Jan 26, 2016 at 4:04 PM, Luis R. Rodriguez <mcgrof@suse.com>
>>>>>>> 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