[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 02:00 PM, Luis R. Rodriguez wrote:
On Wed, Jan 27, 2016 at 10:48 AM, Luis R. Rodriguez <mcgrof@xxxxxxxxxx> wrote:
Worth mentioning here also is hpa's clarification on when subarch type
PC (0) should be used: [it should be used if the hardware is]
"enumerable using standard PC mechanisms (PCI, ACPI) and doesn't need
a special boot flow" -- does that fit HVMLite's description so far? If
so then The Xen subarch may need to be redefined as well to be clear
what it means. I don't think we need to be precise but at the very
least cover grounds to enable the definitions to meet its actual use
to not confuse users.
Another thing to consider for HVMlite is that if the 0 subarch (PC) is
used in light of my linker table work and x86's use of it with the
subarch and supported subarch bitmask, is that it would also mean
HVMLite would run all routines currently pegged as needing PC type
(the current KVM and bare metal path) and it would mean not running
anything only pegged with Xen subarch type (but note that today Xen
doesn't even set the subarch type). If there is nothing in common
between PV and HVMlite (no x86 init calls to share), and if HVMLite
*can* call *alllllllll* PC init calls, then by all means this is fine,

Yes, that's the idea. HVMlite jumps to startup_32|64 from the stub and runs from there with subarch 0.


and if we just need to distinguish stuff between PC types that's fine,
it may still be possible to further extend hypervisor_type to the x86
init calls I'm adding as another supported_hyper_types to ensure even
though a subarch is being used, that we also check the supported
hypervisor type as well.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.