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

From: Boris Ostrovsky
Date: Wed Jan 27 2016 - 11:15:31 EST


On 01/27/2016 10:29 AM, Konrad Rzeszutek Wilk wrote:
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

Yes, I saw that and this will be renamed as paravirt_legacy() (which I am not sure is really what it should be called.)

Another option is to have early microcode code query CPUID to see whether we are running on a hypervisor (this in fact is what we originally thought of doing before realizing that we have paravirt_enabled()).

But then how is HVMlite different from a regular HVM guest trying to load microcode?

(BTW, to answer David's question about what KVM is doing --- it is ignoring writes to microcode MSRs, see kvm_set_msr_common().)

-boris