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:Surely the interesting comparison here is how is (early) microcode
On Jan 26, 2016 6:16 PM, "Luis R. Rodriguez" <mcgrof@xxxxxxxx> wrote:It may help to not think of PVH/hvmlite as PV. It really is HVM with
On Tue, Jan 26, 2016 at 4:04 PM, Luis R. Rodriguez <mcgrof@xxxxxxxx>wrote:
Actually this call can't be used, and if early code used it prior toYou go:Hrm, does HVMlite work well with load_ucode_bsp(), note the patches to
hvmlite_start_xen() -->
HVM stub
startup_64() | (startup_32()
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() ?
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.
a lot
of emulated devices removed.
How does early microcode work on EFI? Does the EFI stub code have an
early
microcode loading code ?
loading disabled in KVM guests? We should use the same mechanism for
I think you missed a word when you read my reply.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).