All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Juergen Gross <jgross@suse.com>
Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	x86@kernel.org, linux-mm@kvack.org, boris.ostrovsky@oracle.com,
	sstabellini@kernel.org, hpa@zytor.com, tglx@linutronix.de,
	mingo@redhat.com, bp@alien8.de
Subject: Re: [PATCH v2 1/2] x86: respect memory size limiting via mem= parameter
Date: Mon, 11 Feb 2019 13:06:50 +0100	[thread overview]
Message-ID: <20190211120650.GA74879@gmail.com> (raw)
In-Reply-To: <20190130082233.23840-2-jgross@suse.com>


* Juergen Gross <jgross@suse.com> wrote:

> When limiting memory size via kernel parameter "mem=" this should be
> respected even in case of memory made accessible via a PCI card.
> 
> Today this kind of memory won't be made usable in initial memory
> setup as the memory won't be visible in E820 map, but it might be
> added when adding PCI devices due to corresponding ACPI table entries.
> 
> Not respecting "mem=" can be corrected by adding a global max_mem_size
> variable set by parse_memopt() which will result in rejecting adding
> memory areas resulting in a memory size above the allowed limit.

So historically 'mem=xxxM' was a way to quickly limit RAM.

If PCI devices had physical mmio memory areas above this range, we'd 
still expect them to work - the option was really only meant to limit 
RAM.

So I'm wondering what the new logic is here - why should an iomem 
resource from a PCI device be ignored? It's a completely separate area 
that might or might not be enumerated in the e820 table - the only 
requirement we have here I think is that it not overlap RAM areas or each 
other (obviously).

So if I understood this new restriction you want mem= to imply, devices 
would start failing to initialize on bare metal when mem= is used?

Thanks,

	Ingo


  parent reply	other threads:[~2019-02-11 12:06 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-30  8:22 [PATCH v2 0/2] x86: respect memory size limits Juergen Gross
2019-01-30  8:22 ` [PATCH v2 1/2] x86: respect memory size limiting via mem= parameter Juergen Gross
2019-02-11 12:06   ` Ingo Molnar
2019-02-11 12:06   ` Ingo Molnar [this message]
2019-02-11 12:14     ` [Xen-devel] " Juergen Gross
2019-02-11 12:23       ` Ingo Molnar
2019-02-11 12:35         ` Juergen Gross
2019-02-11 12:35         ` Juergen Gross
2019-02-11 12:23       ` Ingo Molnar
2019-02-11 12:14     ` Juergen Gross
2019-01-30  8:22 ` Juergen Gross
2019-01-30  8:22 ` [PATCH v2 2/2] x86/xen: dont add memory above max allowed allocation Juergen Gross
2019-01-30  8:22 ` Juergen Gross
2019-01-30 10:59   ` William Kucharski
2019-01-30 10:59   ` William Kucharski
2019-02-01 18:46   ` Boris Ostrovsky
2019-02-07  6:32     ` Juergen Gross
2019-02-07  6:32     ` Juergen Gross
2019-02-01 18:46   ` Boris Ostrovsky

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=20190211120650.GA74879@gmail.com \
    --to=mingo@kernel.org \
    --cc=boris.ostrovsky@oracle.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=jgross@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@redhat.com \
    --cc=sstabellini@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=x86@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.