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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel