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.

  Luis