Messages in this thread |  | | Subject | Re: [PATCH 2/8] x86/head: Refactor 32-bit pgtable setup | From | Boris Ostrovsky <> | Date | Fri, 14 Oct 2016 15:18:47 -0400 |
| |
On 10/14/2016 03:04 PM, hpa@zytor.com wrote: > On October 14, 2016 11:44:18 AM PDT, Boris Ostrovsky <boris.ostrovsky@oracle.com> wrote: >> On 10/14/2016 02:31 PM, hpa@zytor.com wrote: >>> On October 14, 2016 11:05:12 AM PDT, Boris Ostrovsky >> <boris.ostrovsky@oracle.com> wrote: >>>> From: Matt Fleming <matt@codeblueprint.co.uk> >>>> >>>> The new Xen PVH entry point requires page tables to be setup by the >>>> kernel since it is entered with paging disabled. >>>> >>>> Pull the common code out of head_32.S and into pgtable_32.S so that >>>> setup_pgtable_32 can be invoked from both the new Xen entry point >> and >>>> the existing startup_32 code. >>>> >>> And why does it need a separate entry point as opposed to the plain >> one? >> >> One reason is that we need to prepare boot_params before jumping to >> startup_{32|64}. >> >> When the guest is loaded (always in 32-bit mode) the only thing we have >> is a pointer to Xen-specific datastructure. The early PVH code will >> prepare zeropage based on that structure and then jump to regular >> startup_*() code. >> >> -boris > And why not just resume execution at start_32 then?
I am not sure what start_32 is.
If you meant startup_32 then that's exactly what we do (for 32-bit guests) once zeropage is set up.
-boris
-boris
|  |