From: Rusty Russell <rusty@rustcorp.com.au>
To: Avi Kivity <avi@qumranet.com>
Cc: Shaohua Li <shaohua.li@intel.com>,
kvm-devel <kvm-devel@lists.sourceforge.net>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [kvm-devel] [RFC 0/8]KVM: swap out guest pages
Date: Tue, 24 Jul 2007 09:10:18 +1000 [thread overview]
Message-ID: <1185232218.1803.36.camel@localhost.localdomain> (raw)
In-Reply-To: <46A4829C.9080104@qumranet.com>
On Mon, 2007-07-23 at 13:27 +0300, Avi Kivity wrote:
> Having an address_space (like your patch does) is remarkably simple, and
> requires few hooks from the current vm. However using existing vmas
> mapped by the user has many advantages:
>
> - compatible with s390 requirements
> - allows the user to use hugetlbfs pages, which have a performance
> advantage using ept/npt (but which are unswappable)
> - allows the user to map a file (which can be regarded as way to specify
> the swap device)
> - better ingration with the rest of the vm
You don't need to expose the vmas. You just have userspace point out
the start+len of each region of memory it wants the guest to be able to
access, and the address it wants it to appear in the guest.
This is a slight superset of what lguest does in two ways:
1) my guest address == user address, but I'm looking at adding an offset
so I don't have to link the launcher binary specially.
2) I have only one contiguous region of guest-physical memory, since I
can place device memory immediately above "normal" mem.
But the result is pretty sweet, and doesn't require any new symbols to
be exported.
Cheers,
Rusty.
next prev parent reply other threads:[~2007-07-23 23:10 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-23 6:51 [RFC 0/8]KVM: swap out guest pages Shaohua Li
2007-07-23 10:27 ` Avi Kivity
2007-07-23 12:25 ` [kvm-devel] " Christoph Hellwig
2007-07-23 12:29 ` Avi Kivity
2007-07-23 12:34 ` Christoph Hellwig
2007-07-23 12:39 ` Avi Kivity
2007-07-24 2:00 ` Shaohua Li
2007-07-23 20:06 ` Jeff Dike
2007-07-24 5:22 ` Avi Kivity
2007-07-25 16:15 ` Jeff Dike
2007-07-25 17:12 ` [kvm-devel] " Carsten Otte
2007-07-23 23:10 ` Rusty Russell [this message]
2007-07-24 5:30 ` Avi Kivity
2007-07-24 6:11 ` Rusty Russell
2007-07-24 6:21 ` Avi Kivity
2007-07-24 6:45 ` Rusty Russell
2007-07-24 6:59 ` Avi Kivity
2007-07-24 7:17 ` Rusty Russell
2007-07-24 1:42 ` Shaohua Li
2007-07-24 5:42 ` 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=1185232218.1803.36.camel@localhost.localdomain \
--to=rusty@rustcorp.com.au \
--cc=avi@qumranet.com \
--cc=kvm-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=shaohua.li@intel.com \
/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