lkml.org 
[lkml]   [2016]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest
From
Date
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.

-boris

\
 
 \ /
  Last update: 2016-01-27 16:41    [W:0.282 / U:0.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site