All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
To: Michael Riepe <michael-0QoEqw4nQxo@public.gmane.org>
Cc: kvm-devel <kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
Subject: Re: file-backed guest memory
Date: Thu, 12 Apr 2007 18:38:46 +0300	[thread overview]
Message-ID: <461E5286.7090100@qumranet.com> (raw)
In-Reply-To: <461E5181.6010504-0QoEqw4nQxo@public.gmane.org>

Michael Riepe wrote:
> Hi!
>
> This is just a (probably silly) idea I had the other day. Currently, the
> guest's memory is allocated inside the kernel and exported to userspace
> via mmap(). But wouldn't it also be possible to create a file in
> userspace and pass its descriptor to kvm? If we also pass file offset
> and length parameters for each memslot, all segments can (but need not)
> reside in the same file. There would be a persistent snapshot of the
> VM's physical memory, and it would enable the VM to page out the guest's
> pages. One could also do strange things like mapping a portion of the
> file several times, e.g. to emulate an architecture with incomplete
> address decoding. Applications that absolutely want to use anonymous
> memory could pass -1 as the fd, as they do with mmap(MAP_ANONYMOUS).
>   

Arnd suggested this way back when kvm was first posted on lkml, and I 
agree that this is a very useful mechanism.  You get on-demand loading, 
swap, hugetlbfs, and maybe other nifty stuff.  I think I know how to do 
this for the current mmu, but I'm worried that it will have a 
performance impact with the nested page tables mmu.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

  parent reply	other threads:[~2007-04-12 15:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-12 15:34 file-backed guest memory Michael Riepe
     [not found] ` <461E5181.6010504-0QoEqw4nQxo@public.gmane.org>
2007-04-12 15:38   ` Avi Kivity [this message]
     [not found]     ` <461E5286.7090100-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-04-12 15:47       ` Laurent Vivier
     [not found]         ` <461E5497.3090409-6ktuUTfB/bM@public.gmane.org>
2007-04-12 15:56           ` Avi Kivity
2007-04-13  6:57       ` Christian Borntraeger
     [not found]         ` <200704130857.15003.borntrae-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
2007-04-14 14:14           ` Avi Kivity

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=461E5286.7090100@qumranet.com \
    --to=avi-atkuwr5tajbwk0htik3j/w@public.gmane.org \
    --cc=kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=michael-0QoEqw4nQxo@public.gmane.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.