Re: [Draft A] Boot ABI for HVM guests without a device-model

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Thu, Jun 11, 2015 at 08:18:27AM +0100, Jan Beulich wrote:
> >>> On 10.06.15 at 20:55, <konrad.wilk@oracle.com> wrote:
> > On Wed, Jun 10, 2015 at 02:34:00PM +0200, Roger Pau Monné wrote:
> >> The first three notes contain information about the guest kernel and 
> >> the Xen hypercall ABI version. The following notes are of special 
> >> interest:
> >> 
> >>  * XEN_ELFNOTE_PADDR_OFFSET: the offset of the ELF paddr field from the
> >>    actual required physical address.
> >>  * XEN_ELFNOTE_PADDR_ENTRY: the 32bit entry point into the kernel.
> > 
> > Is 'P' suppose to be 'physical' ?
> > 
> > I am not sure how this will work with an ELF 64-bit binary like
> > the Linux kernel. Usually we use the virtual address but with
> > us starting in 32-bit mode with an 64-bit virtual address won't work.
> 
> So first you correctly decode the 'P' as physical, and then you're
> concerned about _virtual_ addresses? The Linux ELF PHDR has
> perfectly valid virtual _and_ physical addresses in it afaict.
> 
> >> Note that the boot protocol resembles the multiboot1 specification, 
> >> this is done so OSes with multiboot1 entry points can reuse those if 
> >> desired. Also note that the processor starts with paging disabled, 
> >> which means that all the memory addresses in the start_info page will 
> >> be physical memory addresses.
> > 
> > Wow?! Pagetables disabled?! Why? Usually boot loaders start with some
> > pagetables setup for the OS - to cover at least the kernel and the
> > ramdisk. Either it being in 1-1 pagetables or such.
> 
> Mind pointing out which boot loaders you think about here? Both
> multiboot variants surely start the OS in non-paged protected
> mode. Of course, UEFI is completely different (because it wants
> itself to run in 64-bit mode).

I was thinking of UEFI. Other ones as you pointed out are more
primitive.
> 
> Jan