From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [Draft A] Boot ABI for HVM guests without a device-model Date: Fri, 12 Jun 2015 09:30:21 -0400 Message-ID: <20150612133021.GC15651@l.oracle.com> References: <55782EB8.1060708@citrix.com> <20150610185533.GA4214@l.oracle.com> <5579526302000078000835E0@mail.emea.novell.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 1Z3P2V-0004Rc-LT for xen-devel@lists.xenproject.org; Fri, 12 Jun 2015 13:30:31 +0000 Content-Disposition: inline In-Reply-To: <5579526302000078000835E0@mail.emea.novell.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: Jan Beulich Cc: Elena Ufimtseva , Ian Campbell , Stefano Stabellini , Andrew Cooper , Tim Deegan , xen-devel , Boris Ostrovsky , roger.pau@citrix.com List-Id: xen-devel@lists.xenproject.org On Thu, Jun 11, 2015 at 08:18:27AM +0100, Jan Beulich wrote: > >>> On 10.06.15 at 20:55, wrote: > > On Wed, Jun 10, 2015 at 02:34:00PM +0200, Roger Pau Monn=E9 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