From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S933001AbcJNTFJ (ORCPT <rfc822;w@1wt.eu>);
        Fri, 14 Oct 2016 15:05:09 -0400
Received: from terminus.zytor.com ([198.137.202.10]:58394 "EHLO mail.zytor.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1753784AbcJNTFD (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 14 Oct 2016 15:05:03 -0400
User-Agent: K-9 Mail for Android
In-Reply-To: <1325167d-34fa-2ea1-e9c5-8e9fc727a363@oracle.com>
References: <1476468318-24422-1-git-send-email-boris.ostrovsky@oracle.com> <1476468318-24422-3-git-send-email-boris.ostrovsky@oracle.com> <119777C5-564B-4171-9452-3E216BC7442E@zytor.com> <1325167d-34fa-2ea1-e9c5-8e9fc727a363@oracle.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Subject: Re: [PATCH 2/8] x86/head: Refactor 32-bit pgtable setup
From: hpa@zytor.com
Date: Fri, 14 Oct 2016 12:04:42 -0700
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>, david.vrabel@citrix.com,
        JGross@suse.com
CC: roger.pau@citrix.com, linux-kernel@vger.kernel.org,
        xen-devel@lists.xenproject.org, Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, x86@kernel.org,
        Matt Fleming <matt@codeblueprint.co.uk>
Message-ID: <CFB7B4F4-CE78-4129-BB4E-A599384E7A42@zytor.com>
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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?
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.