LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Randy Dunlap <randy.dunlap@oracle.com>
To: Andrea Arcangeli <andrea@qumranet.com>
Cc: linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>,
	Nick Piggin <npiggin@suse.de>
Subject: Re: [PATCH] reserve RAM below PHYSICAL_START
Date: Wed, 27 Feb 2008 15:50:33 -0800	[thread overview]
Message-ID: <20080227155033.e1fef26b.randy.dunlap@oracle.com> (raw)
In-Reply-To: <20080227003325.GS28483@v2.random>

On Wed, 27 Feb 2008 01:33:25 +0100 Andrea Arcangeli wrote:

> Hello,
> 
> this patch allows to prevent linux from using the ram below
> PHYSICAL_START.
> 
> The "reserved RAM" can be mapped by virtualization software with to
> create a 1:1 mapping between guest physical (bus) address and host
> physical (bus) address. This will allow pci passthrough with DMA for
> the guest with current production hardware that misses VT-d. The only
> detail to take care of is the ram marked "reserved RAM failed". The
> virtualization software must create for the guest an e820 map that
> only includes the "reserved RAM" regions but if the guest touches
> memory with guest physical address in the "reserved RAM failed" ranges
> (linux guest will do that even if the ram isn't present in the e820
> map), it should provide that as ram and map it with a not-ident
> mapping. This should allow any linux kernel to run fine with pci
> passthrough and hopefully any other OS too with all VT enabled
> hardware.
> 
> 
> Let me know if this can be merged, thanks!
> 
> 
> Signed-off-by: Andrea Arcangeli <andrea@qumranet.com>
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1109,8 +1109,36 @@ config CRASH_DUMP
>  	  (CONFIG_RELOCATABLE=y).
>  	  For more details see Documentation/kdump/kdump.txt
>  
> +config RESERVE_PHYSICAL_START
> +	bool "Reserve all RAM below PHYSICAL_START (EXPERIMENTAL)"
> +	depends on !RELOCATABLE && X86_64
> +	help
> +	  This makes the kernel use only RAM above __PHYSICAL_START.
> +	  All memory below __PHYSICAL_START will be left unused and
> +	  marked as "reserved RAM" in /proc/iomem. The few special
> +	  pages that can't be relocated at addresses above
> +	  __PHYSICAL_START and that can't be guaranteed to be unused
> +	  by the running kernel, will be marked "reserved RAM failed"

No comma.

> +	  in /proc/iomem. Those may or may be not used by the kernel
> +	  (for example smp trampoline pages would only be used if

                       SMP

> +	  CPU hotplug is enabled).
> +
> +          The "reserved RAM" can be mapped by virtualization software

Indent above with tab + 2 spaces, please.

> +	  with /dev/mem to create a 1:1 mapping between guest physical
> +	  (bus) address and host physical (bus) address. This will
> +	  allow pci passthrough with DMA for the guest using the ram

                PCI                                              RAM

> +	  with the 1:1 mapping. The only detail to take care of is the
> +	  ram marked "reserved RAM failed". The virtualization

          RAM

> +	  software must create for the guest an e820 map that only
> +	  includes the "reserved RAM" regions but if the guest touches
> +	  memory with guest physical address in the "reserved RAM
> +	  failed" ranges (linux guest will do that even if the ram

                          Linux                                RAM

> +	  isn't present in the e820 map), it should provide that as
> +	  ram and map it with a non linear mapping. This should allow

          RAM                   non-linear

> +	  any linux kernel to run fine and hopefully any other OS too.

              Linux

> +
>  config PHYSICAL_START
> -	hex "Physical address where the kernel is loaded" if (EMBEDDED || CRASH_DUMP)
> +	hex "Physical address where the kernel is loaded" if (EMBEDDED || CRASH_DUMP || RESERVE_PHYSICAL_START)
>  	default "0x1000000" if X86_NUMAQ
>  	default "0x200000" if X86_64
>  	default "0x100000"


---
~Randy

  reply	other threads:[~2008-02-27 23:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-27  0:33 [PATCH] reserve RAM below PHYSICAL_START Andrea Arcangeli
2008-02-27 23:50 ` Randy Dunlap [this message]
2008-02-28 18:36 ` Vivek Goyal
2008-02-29 19:12   ` Andrea Arcangeli
2008-02-29 18:21 ` H. Peter Anvin
2008-02-29 18:50   ` Andrea Arcangeli
2008-03-03 12:17 ` Andi Kleen
2008-03-10  0:33   ` Andrea Arcangeli

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=20080227155033.e1fef26b.randy.dunlap@oracle.com \
    --to=randy.dunlap@oracle.com \
    --cc=akpm@osdl.org \
    --cc=andrea@qumranet.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=npiggin@suse.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).