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
next prev parent 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: linkBe 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).