Re: [Xen-devel] [PATCH v3 00/32] Introduce HVM without dm and new boot ABI

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Fri, Jul 03, 2015 at 06:36:37PM +0200, Roger Pau Monné 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=people/royger/freebsd.git;a=blob;f=sys/amd64/amd64/xen-locore32.S;h=fd73d150009ab21059d4df219e6a62cc40d5994e;hb=refs/heads/new_entry_point_v2
> 
> Roger.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel