LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@qumranet.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>,
	Nick Piggin <npiggin@suse.de>, Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH] reserve RAM below PHYSICAL_START
Date: Fri, 29 Feb 2008 19:50:29 +0100	[thread overview]
Message-ID: <20080229185029.GZ8091@v2.random> (raw)
In-Reply-To: <47C84D14.2000400@zytor.com>

Hi Peter,

On Fri, Feb 29, 2008 at 10:21:08AM -0800, H. Peter Anvin wrote:
> Hi Andrea,
>
> Sorry for the long delay in replying.
>
> I'm trying to grok the use cases for this.  In particular, it seems like a 
> particularly restricted case of wanting to be able to reserve an arbitrary 
> bit of memory, which seems like it would be more useful (don't we already 
> have memmap= options for that, anyway?)

I'll answer the memmap in separate email.

> In particular, what's the reason for reserving *low* memory?  Low memory 
> (first megabyte) is full of special-use address space which, as the Xen 

The only special ones are zero page and trampoline (the trampoline
optionally can later be moved near 640k with an independent patch).

> address space discussion has showed, is nontrivial to tamper with even if 
> it initially works.  If you want a dedicated chunk of mappable PCI space, 
> it would seem cleaner to have it higher up in the memory map.

The whole e820 must be PCI mappable, bootloader starts in real mode
and if any dma happens it will crash. This is to let any guest OS or
bootloader run with pci passthrough. There's no paravirt here, the
guest has fully native drivers (which is the whole point of this
approach I guess).

This will allow things like running random 3d apps on a random 3d card
on random OS with random 3d driver, all on top of linux host that
leaves the first 1G free for this OS to run with direct access to the
graphics card. Clearly linux host isn't safe, but if you trust that
guest OS that talks directly to the 3d card, you can run many more
guests that are fully swapped out or ballooned or rss limited or ksm
shared, etc... plus the host can run apps too. This is to retain the
full KVM/Linux virtualization power and flexibility without leaving 3d
or any other proprietary hardware out of the equation in the
pci-passthrough guest.

  reply	other threads:[~2008-02-29 18:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-27  0:33 Andrea Arcangeli
2008-02-27 23:50 ` Randy Dunlap
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 [this message]
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=20080229185029.GZ8091@v2.random \
    --to=andrea@qumranet.com \
    --cc=akpm@osdl.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=npiggin@suse.de \
    --subject='Re: [PATCH] reserve RAM below PHYSICAL_START' \
    /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

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).