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

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

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 ?

> 
>   Luis

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


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