All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@arm.com>
To: Andrii Anisov <andrii.anisov@gmail.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Cc: Matthew Daley <mattd@bugfuzz.com>,
	"sstabellini@kernel.org" <sstabellini@kernel.org>
Subject: Re: [PATCH for-4.12 v2 2/2] xen/arm: Stop relocating Xen
Date: Mon, 17 Dec 2018 13:38:42 +0000	[thread overview]
Message-ID: <c60e066b-2042-cc58-f4f0-3a066eae1d76@arm.com> (raw)
In-Reply-To: <afc1075d-9bf7-4ca5-a3b0-b52dbcb16dd0@gmail.com>

Hi,

On 17/12/2018 13:14, Andrii Anisov wrote:
> 
> 
> On 14.12.18 19:48, Julien Grall wrote:
>> Please try to reference the documentation (or code if lack of documentation) 
>> when making such statement.
> 
> Ah, yes, sure.
> 
>> AFAICT, Linux 32-bit [1] imposes the kernel to be loaded in the first 128MB of 
>> RAM. Nothing about the 128MB aligned RAM.
> 
> Right, the documentation sets a restriction for a compressed image to be loaded 
> in the first 128MB of RAM. But the comment in a decompressor code (and the code 
> itself) explicitly refer alignment [11].
> Calculating a RAM start address with this mask [22] give us a wrong value if the 
> real physical address is 64MB aligned, not 128MB. Then crash on decompressing. 
> You know, I stepped into that with J6 (arm32) while setting up thin Dom0 with 
> only 64MB RAM.

Thank you for the pointer.

> 
>> Linux 64-bit [1] requires to be loaded at a 2MB aligned address.
> 
> Great, 64-bit Linux documentation directly refers the alignment :)
> 
>> So technically allocating the RAM using a 2MB alignment should be enough.
> 
> For 64-bit and, maybe, raw 32-bit Linux kernel images.
> For 32-bit compressed Linux kernel - still 128MB aligned first bank is required.
> It can be changed on kernel side by setting ZRELADDR, but we can't designate 
> that from XEN runtime.

I also don't think this would be a good approach as we still want to keep the 
kernel as much as possible position independent.

> 
>> Yet we need to make sure the first bank is at least 128MB.
> 
> Well, I'm not sure the ARM64 documentation [33] or implementation mention the 
> size of the first bank. Except it should be enough to hold the kernel image [44].
> Also I would not treat [55] as a strict requirement to have 128MB in the first 
> bank. But we can stick at that to make things easier.

The size of the first bank is implicit on arm32. If you look at the 
Documentation/arm32/Booting.txt, the DTB/initramfs should be loaded just above 
128MB to avoid the decompressor to avoid overwrite them. So technically, we 
should allow more than 128MB for the first bank.

At the moment, the algorithm to load 64-bit and 32-bit Image are the same. Hence 
why I said we need at least 128MB in the first bank. I am open for using 
different algorithm if Dom0 should be smaller.

Cheers,

-- 
Julien Grall

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

  reply	other threads:[~2018-12-17 13:38 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-14 11:44 [PATCH for-4.12 v2 0/2] xen/arm: mm: Boot fixes Julien Grall
2018-12-14 11:44 ` [PATCH for-4.12 v2 1/2] xen/arm: mm: Use pte_xen_addr when creating xen entries Julien Grall
2018-12-14 21:44   ` Stefano Stabellini
2018-12-14 11:44 ` [PATCH for-4.12 v2 2/2] xen/arm: Stop relocating Xen Julien Grall
2018-12-14 15:52   ` Andrii Anisov
2018-12-14 16:09     ` Andrii Anisov
2018-12-14 16:26     ` Julien Grall
2018-12-14 17:24       ` Andrii Anisov
2018-12-14 17:48         ` Julien Grall
2018-12-17 11:11           ` Julien Grall
2018-12-17 16:02             ` Andrii Anisov
2018-12-17 16:56               ` Julien Grall
2018-12-17 17:57             ` Stefano Stabellini
2018-12-17 18:03               ` Julien Grall
2018-12-17 13:14           ` Andrii Anisov
2018-12-17 13:38             ` Julien Grall [this message]
2018-12-17 15:55               ` Andrii Anisov
2018-12-17 17:02                 ` Julien Grall
2018-12-17 17:34                   ` Andrii Anisov
2018-12-18 12:09                     ` Andrii Anisov
2018-12-18 13:13                       ` Julien Grall
2018-12-14 17:46       ` Andrii Anisov
2018-12-14 18:04         ` Julien Grall
2018-12-17 15:54           ` Andrii Anisov
2018-12-17 17:03             ` Julien Grall
2018-12-14 16:13   ` Andrii Anisov

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=c60e066b-2042-cc58-f4f0-3a066eae1d76@arm.com \
    --to=julien.grall@arm.com \
    --cc=andrii.anisov@gmail.com \
    --cc=mattd@bugfuzz.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xen.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.