[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest
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). -boris _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |