From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH v3 00/32] Introduce HVM without dm and new boot ABI Date: Fri, 10 Jul 2015 13:44:58 -0400 Message-ID: <20150710174458.GA28281@l.oracle.com> References: <1435923310-9019-1-git-send-email-roger.pau@citrix.com> <5596B62E.7010306@citrix.com> <5596BA15.2090507@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDcMC-0001tc-UB for xen-devel@lists.xenproject.org; Fri, 10 Jul 2015 17:45:05 +0000 Content-Disposition: inline In-Reply-To: <5596BA15.2090507@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Roger Pau =?iso-8859-1?Q?Monn=E9?= Cc: xen-devel@lists.xenproject.org, David Vrabel List-Id: xen-devel@lists.xenproject.org On Fri, Jul 03, 2015 at 06:36:37PM +0200, Roger Pau Monn=E9 wrote: > El 03/07/15 a les 18.19, David Vrabel ha escrit: > > On 03/07/15 12:34, Roger Pau Monne wrote: > >> > >> And for the FreeBSD part: > > = > > Have you thought at all about what the Linux support for this mode would > > look like? > > = > > I started briefly looking today but don't really have time to look into > > it properly. I do think we want to use as much of the native/HVM code > > as possible and avoid the PV path (the current Linux PVH code uses too > > much of the PV entry point, IMO). > = > I'm afraid I'm not that familiar with the native Linux entry point in > order to know how much of that can be reused. Does the amd64 kernel > contain a 32bit entry point or the kernel is expected to be launched in > long mode with some page tables already setup? It does : arch/x86/kernel/head_64[32].S:startup_32 The problem is that it depends to have the boot_params (a Linux structure) filled out. Which then calls 'default_entry' [32-bit] or 'startup_64', and then it goes off somewhere (there is a lot of EFI code in there). Anyhow it eventually ends up: x86_64_start_kernel -> x86_64_start_reservations = But the problem is that during this execution none of the pvops get set to the Xen ones (which we need to tell the kernel that there is almost no hardware). One could change initial_code to some xen_x86_64_start_kernel that would be similar to xen_startup - in that it would set up the basic pvops structures and then call x86_64_start_kernel. In essence something like: startup_32 \-> startup_64 [in compressed/head_64.S] \-> startup_64 [ head_64.S] \-> secondary_startup_64 \-> jmpq *initial_code [which is by default x86_64_start_kernel] = [if I got the assmebler call chain correctly figured out] = > Iff Linux on i386/amd64 already contains a 32bit protected mode without > paging entry point then I guess most of the code can be reused. Yes except that we would have to have before then to fill out the boot_params to get use going, setup the initial stack. The during the bootup we would need to swap over to an Xen entry point so that it can neuter most of the pvops calls. > = > Note that FreeBSD/amd64 didn't have any of this (the kernel is launched > in long mode with some initial page tables setup by the loader), so the > code needed for Linux should be similar to the one on FreeBSD or even > less if there's an entry point that we can reuse:a The Linux kernel can also start in 32/64-bit mode with page tables (thanks to EFI) > = > http://xenbits.xen.org/gitweb/?p=3Dpeople/royger/freebsd.git;a=3Dblob;f= =3Dsys/amd64/amd64/xen-locore32.S;h=3Dfd73d150009ab21059d4df219e6a62cc40d59= 94e;hb=3Drefs/heads/new_entry_point_v2 > = > Roger. > = > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel