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 17:17:16 +1000 [thread overview]
Message-ID: <1185261436.1803.254.camel@localhost.localdomain> (raw)
In-Reply-To: <46A5A36E.8000409@qumranet.com>
On Tue, 2007-07-24 at 09:59 +0300, Avi Kivity wrote:
> However, you can probably work around that by not setting an rmap for
> the kernel mappings, and instead have the guest teach the host where the
> kernel page tables live. You'd only be left with shared libraries,
> until the kernel can share page tables for them too.
Well, I already treat kernel mappings specially (effectively I know the
guest's PAGE_OFFSET): they're kept identical in all the 4 shadows, and
need explicit guest flushing.
Whether the guest shares (non-kernel) page tables or not, I will shadow
them dumb as separate page table pages the way things stand. So, yes,
shared libs will be my main issue. Address space randomization means I
can't even use a heuristic such as looking for the page at the same
address in other shadows. I'll come up with something.
Anyway, virtio what I'm *supposed* to be doing today...
Thanks,
Rusty.
WARNING: multiple messages have this Message-ID (diff)
From: Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
To: Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
Cc: kvm-devel
<kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>,
lkml <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [RFC 0/8]KVM: swap out guest pages
Date: Tue, 24 Jul 2007 17:17:16 +1000 [thread overview]
Message-ID: <1185261436.1803.254.camel@localhost.localdomain> (raw)
In-Reply-To: <46A5A36E.8000409-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
On Tue, 2007-07-24 at 09:59 +0300, Avi Kivity wrote:
> However, you can probably work around that by not setting an rmap for
> the kernel mappings, and instead have the guest teach the host where the
> kernel page tables live. You'd only be left with shared libraries,
> until the kernel can share page tables for them too.
Well, I already treat kernel mappings specially (effectively I know the
guest's PAGE_OFFSET): they're kept identical in all the 4 shadows, and
need explicit guest flushing.
Whether the guest shares (non-kernel) page tables or not, I will shadow
them dumb as separate page table pages the way things stand. So, yes,
shared libs will be my main issue. Address space randomization means I
can't even use a heuristic such as looking for the page at the same
address in other shadows. I'll come up with something.
Anyway, virtio what I'm *supposed* to be doing today...
Thanks,
Rusty.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
next prev parent reply other threads:[~2007-07-24 7:17 UTC|newest]
Thread overview: 39+ 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 6:51 ` Shaohua Li
2007-07-23 10:27 ` Avi Kivity
2007-07-23 10:27 ` Avi Kivity
2007-07-23 12:25 ` [kvm-devel] " Christoph Hellwig
2007-07-23 12:25 ` Christoph Hellwig
2007-07-23 12:29 ` [kvm-devel] " Avi Kivity
2007-07-23 12:29 ` Avi Kivity
2007-07-23 12:34 ` [kvm-devel] " Christoph Hellwig
2007-07-23 12:34 ` Christoph Hellwig
2007-07-23 12:39 ` [kvm-devel] " Avi Kivity
2007-07-23 12:39 ` Avi Kivity
2007-07-24 2:00 ` [kvm-devel] " Shaohua Li
2007-07-24 2:00 ` Shaohua Li
2007-07-23 20:06 ` Jeff Dike
2007-07-23 20:06 ` Jeff Dike
2007-07-24 5:22 ` Avi Kivity
2007-07-24 5:22 ` Avi Kivity
2007-07-25 16:15 ` Jeff Dike
2007-07-25 16:15 ` Jeff Dike
2007-07-25 17:12 ` [kvm-devel] " Carsten Otte
2007-07-25 17:12 ` Carsten Otte
2007-07-23 23:10 ` [kvm-devel] " Rusty Russell
2007-07-23 23:10 ` Rusty Russell
2007-07-24 5:30 ` [kvm-devel] " Avi Kivity
2007-07-24 6:11 ` Rusty Russell
2007-07-24 6:11 ` Rusty Russell
2007-07-24 6:21 ` [kvm-devel] " Avi Kivity
2007-07-24 6:21 ` Avi Kivity
2007-07-24 6:45 ` [kvm-devel] " Rusty Russell
2007-07-24 6:45 ` Rusty Russell
2007-07-24 6:59 ` [kvm-devel] " Avi Kivity
2007-07-24 6:59 ` Avi Kivity
2007-07-24 7:17 ` Rusty Russell [this message]
2007-07-24 7:17 ` Rusty Russell
2007-07-24 1:42 ` Shaohua Li
2007-07-24 1:42 ` Shaohua Li
2007-07-24 5:42 ` Avi Kivity
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=1185261436.1803.254.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 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.