All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Kiper <daniel.kiper@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Juergen Gross <JGross@suse.com>,
	sstabellini@kernel.org, andrew.cooper3@citrix.com,
	cardoe@cardoe.com, pgnet.dev@gmail.com, ning.sun@intel.com,
	julien.grall@arm.com, xen-devel@lists.xenproject.org,
	qiaowei.ren@intel.com, gang.wei@intel.com, fu.wei@linaro.org
Subject: Re: [PATCH v16 5/9] x86: change default load address from 1 MiB to 2 MiB
Date: Mon, 6 Mar 2017 15:51:25 +0100	[thread overview]
Message-ID: <20170306145125.GS8142@olila.local.net-space.pl> (raw)
In-Reply-To: <58B6BCCF020000780013EA4C@prv-mh.provo.novell.com>

On Wed, Mar 01, 2017 at 04:21:35AM -0700, Jan Beulich wrote:
> >>> On 01.03.17 at 11:51, <daniel.kiper@oracle.com> wrote:
> > On Wed, Mar 01, 2017 at 03:34:47AM -0700, Jan Beulich wrote:
> >> >>> On 01.03.17 at 11:13, <daniel.kiper@oracle.com> wrote:
> >> > On Wed, Mar 01, 2017 at 02:05:39AM -0700, Jan Beulich wrote:
> >> >> >>> On 21.02.17 at 20:19, <daniel.kiper@oracle.com> wrote:
> >> >> > Subsequent patches introducing relocatable early boot code play with
> >> >> > page tables using 2 MiB huge pages. If load address is not aligned at
> >> >> > 2 MiB then code touching such page tables must have special cases for
> >> >> > start and end of Xen image memory region. So, let's make life easier
> >> >> > and move default load address from 1 MiB to 2 MiB. This way page table
> >> >> > code will be nice and easy. Hence, there is a chance that it will be
> >> >> > less error prone too... :-)))
> >> >> >
> >> >> > Additionally, drop first 2 MiB mapping from Xen image mapping.
> >> >> > It is no longer needed.
> >> >>
> >> >> What about the memory allocated for it? Aiui at least in the xen.efi
> >> >> case there would be a 2Mb chunk left unused, but also never freed.
> >> >
> >> > Memory is not allocated for it.
> >>
> >> Are you sure? Where would the PE32+ header live in that case?
> >
> > Is the PE32+ header loaded into memory? I think that only code and data stuff
> > is put there. Header is useful only for loader. Am I missing something?
>
> I think EFI's loader simply follows Windows' one(s). And yes, the

Sadly, I do not know how Windows' one(s) work(s).

> headers can be useful - to the loader itself (albeit then the loader
> assumes that no-one fiddles with them).

I have looked at OVMF. It looks that OVMF loads PE32+ header aside, parses it, puts
Xen code and data into allocated memory (EfiLoaderCode type), does relocations and
jumps into entry point. So, more or less as I expected. It looks that it does not
load whole file at once. Hence, taking into account that memory allocated for Xen
image is marked as EfiLoaderCode it means that from Xen point of view this region
is free. Of course later everything between _start and _end is reserved. So, it
seems to me that everything between __image_base__ and _start is free and
available for Xen memory allocator. Am I missing something here?

Daniel

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

  reply	other threads:[~2017-03-06 14:51 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-21 19:19 [PATCH v16 0/9] x86: multiboot2 protocol support Daniel Kiper
2017-02-21 19:19 ` [PATCH v16 1/9] x86: add " Daniel Kiper
2017-02-21 19:19 ` [PATCH v16 2/9] efi: build xen.gz with EFI code Daniel Kiper
2017-02-21 19:19 ` [PATCH v16 3/9] efi: create new early memory allocator Daniel Kiper
2017-02-21 19:19 ` [PATCH v16 4/9] x86: add multiboot2 protocol support for EFI platforms Daniel Kiper
2017-02-21 19:24   ` Daniel Kiper
2017-02-22 13:42     ` Jan Beulich
2017-02-22 13:46       ` Doug Goldstein
2017-02-22 15:34       ` Daniel Kiper
2017-02-22 17:04         ` Doug Goldstein
2017-03-06 23:39           ` Daniel Kiper
2017-03-08  3:44             ` Konrad Rzeszutek Wilk
2017-03-08 14:17               ` Daniel Kiper
2017-03-08 16:46                 ` Konrad Rzeszutek Wilk
2017-03-09 20:02               ` Doug Goldstein
2017-03-09 22:20                 ` Konrad Rzeszutek Wilk
2017-03-15 11:35                 ` Daniel Kiper
2017-03-15 14:27                   ` Doug Goldstein
2017-03-15 14:38                     ` Daniel Kiper
2017-03-15 14:42                       ` Doug Goldstein
2017-03-15 15:02                         ` Daniel Kiper
2017-03-16 12:12                     ` Daniel Kiper
2017-03-16 13:12                       ` Jan Beulich
2017-03-16 13:35                         ` Daniel Kiper
2017-03-16 13:43                           ` Jan Beulich
2017-03-21 13:05                             ` Daniel Kiper
2017-03-21 13:48                               ` Jan Beulich
2017-03-09 15:24             ` Daniel Kiper
2017-03-09 15:41               ` Andrew Cooper
2017-03-09 15:45               ` Jan Beulich
2017-02-21 19:19 ` [PATCH v16 5/9] x86: change default load address from 1 MiB to 2 MiB Daniel Kiper
2017-03-01  9:05   ` Jan Beulich
2017-03-01 10:13     ` Daniel Kiper
2017-03-01 10:34       ` Jan Beulich
2017-03-01 10:51         ` Daniel Kiper
2017-03-01 11:21           ` Jan Beulich
2017-03-06 14:51             ` Daniel Kiper [this message]
2017-03-06 14:59               ` Jan Beulich
2017-02-21 19:19 ` [PATCH v16 6/9] x86/setup: use XEN_IMG_OFFSET instead of Daniel Kiper
2017-02-21 19:19 ` [PATCH v16 7/9] x86: make Xen early boot code relocatable Daniel Kiper
2017-04-07 11:23   ` Jan Beulich
2017-04-13 14:11     ` Daniel Kiper
2017-04-13 19:43       ` Doug Goldstein
2017-04-14 10:46         ` Daniel Kiper
2017-04-14  1:44       ` Konrad Rzeszutek Wilk
2017-04-14 10:50         ` Daniel Kiper
2017-02-21 19:19 ` [PATCH v16 8/9] x86/boot: rename sym_phys() to sym_offs() Daniel Kiper
2017-02-21 19:19 ` [PATCH v16 9/9] x86: add multiboot2 protocol support for relocatable images Daniel Kiper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170306145125.GS8142@olila.local.net-space.pl \
    --to=daniel.kiper@oracle.com \
    --cc=JBeulich@suse.com \
    --cc=JGross@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=cardoe@cardoe.com \
    --cc=fu.wei@linaro.org \
    --cc=gang.wei@intel.com \
    --cc=julien.grall@arm.com \
    --cc=ning.sun@intel.com \
    --cc=pgnet.dev@gmail.com \
    --cc=qiaowei.ren@intel.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.