[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). -boris _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |