All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Xenia Ragiadakou <xenia.ragiadakou@amd.com>
Cc: xen-devel@lists.xenproject.org, Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>
Subject: Re: [PATCH v2] x86/hvm/dom0: fix PVH initrd and metadata placement
Date: Mon, 30 Oct 2023 17:37:31 +0100	[thread overview]
Message-ID: <ZT_by3lesO5TWdy_@macbook> (raw)
In-Reply-To: <20231030133240.116758-1-xenia.ragiadakou@amd.com>

On Mon, Oct 30, 2023 at 03:32:40PM +0200, Xenia Ragiadakou wrote:
> Given that start < kernel_end and end > kernel_start, the logic that
> determines the best placement for dom0 initrd and metadata, does not
> take into account the three cases below:
> (1) start > kernel_start && end > kernel_end
> (2) start < kernel_start && end < kernel_end
> (3) start > kernel_start && end < kernel_end
> 
> In case (1), the evaluation will result in end = kernel_start,
> i.e. end < start, and will load initrd in the middle of the kernel.
> In case (2), the evaluation will result in start = kernel_end,
> i.e. end < start, and will load initrd at kernel_end, that is out
> of the memory region under evaluation.
> In case (3), the evaluation will result in either end = kernel_start
> or start = kernel_end but in both cases will be end < start, and
> will either load initrd in the middle of the image, or arbitrarily
> at kernel_end.
> 
> This patch reorganizes the conditionals to include so far unconsidered
> cases as well, uniformly returning the lowest available address.

It would be good to mention that this was discovered because Zephyr
has multiple loaded segments in non-contiguous ranges, so that we know
what triggered the change and how we could test further improvements
(like the usage of a rangeset).

> 
> Fixes: 73b47eea2104 ('x86/dom0: improve PVH initrd and metadata placement')
> Signed-off-by: Xenia Ragiadakou <xenia.ragiadakou@amd.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

With the commit message adjusted preferably.

Thanks, Roger.


      reply	other threads:[~2023-10-30 16:37 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-30 13:32 [PATCH v2] x86/hvm/dom0: fix PVH initrd and metadata placement Xenia Ragiadakou
2023-10-30 16:37 ` Roger Pau Monné [this message]

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=ZT_by3lesO5TWdy_@macbook \
    --to=roger.pau@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    --cc=xenia.ragiadakou@amd.com \
    /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.