[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/26/2016 01:46 PM, Andy Lutomirski wrote:
On Tue, Jan 26, 2016 at 10:34 AM, Luis R. Rodriguez <mcgrof@xxxxxxxx> wrote:
On Mon, Jan 25, 2016 at 05:28:08PM -0500, Boris Ostrovsky wrote:
On 01/25/2016 04:21 PM, H. Peter Anvin wrote:
On 01/25/16 13:12, Luis R. Rodriguez wrote:
Perhaps, but someone would still have to set hardware_subarch. And
it's hvmlite_bootparams() that does it.
No, Xen would do it as well, essentially all of hvmlite_bootparams() could be
done in Xen.

Or a stub code.
This patch in fact is the stub for Xen HVMlite guests, after we are
done with it we jump to bare-metal startup code (i.e startup_32|64)
Right the point is the stub need not be in Linux, I'll explain in the other
thread where I provided more details on the different known approaches.

ISTM if the Xen ABI-specified entry point has a different convention
than the Linux native entry, then the stub should live in Linux.  It
would be just a couple if lines of code, right?

It's not exactly a couple of lines but it's not large neither. It mainly sets up boot_params (similar to what make_boot_params() does for EFI). Plus, for 64-bit, it loads identity page tables and switches to long mode. And then jumps to bare-meta startup code.

The issue that caused headaches in the past isn't that there's code
that's executed only on native, it's that there are whole big
functions that are executed only on native for no good reason and that
aren't clearly marked.

This won't happen with HVMlite.

If we had native_start_kernel and xen_start_kernel, and they both
called very quickly in to common_start_kernel, it would be very clear
what's going on.

What is now xen_start_kernel() is no longer the entry point for HVMlite. It is called as x86_init.oem.arch_setup() (or I may even move it to x86_hyper_xen.init_platform() or something like that).


Xen-devel mailing list



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