All of lore.kernel.org
 help / color / mirror / Atom feed
From: <dinhngoc.tu@irit.fr>
To: "'Jan Beulich'" <jbeulich@suse.com>
Cc: <xen-devel@lists.xenproject.org>
Subject: RE: [PATCH v2] x86: Use low memory size directly from Multiboot
Date: Wed, 9 Feb 2022 16:20:23 +0100	[thread overview]
Message-ID: <000801d81dc8$8f15b9a0$ad412ce0$@irit.fr> (raw)
In-Reply-To: <ad339015-c5e7-d776-17a3-2dbd337fcd4a@suse.com>

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Wednesday, 9 February 2022 15:26
> To: Tu Dinh Ngoc <dinhngoc.tu@irit.fr>
> Cc: xen-devel@lists.xenproject.org
> Subject: Re: [PATCH v2] x86: Use low memory size directly from Multiboot
> 
> On 09.02.2022 14:12, Tu Dinh Ngoc wrote:
> > Previously, Xen used information from the BDA to detect the amount of
> > available low memory. This does not work on some scenarios such as
> > Coreboot, or when booting from Kexec on a UEFI system without CSM.
> >
> > Use the information directly supplied by Multiboot boot information
> > instead.
> > ---
> 
> Btw - please summarize here briefly what has changed from the earlier
> version. As it stands your adjustment looks to take care of one third of what I
> did say in reply to your v1. That's not enough for a v2, or else you should have
> taken care of the remaining aspects verbally.
> 
> Jan

Hi,

> The comment here is a pretty clear indication that bad values may have been observed, even if this was only in the distant past. But we have to not regress even on very old boot loaders.

> Is the kexec case recognizable by any means (including to distinguish kexec properly communicating the value vs it not doing so, as iirc it was said on irc that this didn't always work correctly there), such that we could skip using the BDA value in that case?

As written in the comments, old versions of kexec (before 2.0.23) presented the amount of lower and upper memory in the BASIC_MEMINFO Multiboot2 tag in bytes instead of kilobytes. The v2 patch tries to detect this condition by checking if there's more than 640 KB of low memory and corrects the low memory size in that case.

This change should only affect the particular case of booting with Multiboot2 without EFI (e.g. legacy BIOS or Kexec). Other cases like Multiboot 0.x, EFI booting (with or without MB2), or bootloaders that generate the BASIC_MEMINFO tag correctly shouldn't be affected.



  reply	other threads:[~2022-02-09 15:20 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-09 11:00 [PATCH] x86: Use low memory size directly from Multiboot dinhngoc.tu
2022-02-09 11:25 ` Jan Beulich
2022-02-09 11:46   ` dinhngoc.tu
2022-02-09 13:12   ` [PATCH v2] " Tu Dinh Ngoc
2022-02-09 14:25     ` Jan Beulich
2022-02-09 15:20       ` dinhngoc.tu [this message]
2022-02-09 15:22         ` Jan Beulich
2022-02-09 15:36           ` dinhngoc.tu
2022-02-09 15:56     ` Roger Pau Monné

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='000801d81dc8$8f15b9a0$ad412ce0$@irit.fr' \
    --to=dinhngoc.tu@irit.fr \
    --cc=jbeulich@suse.com \
    --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.