From: Avi Kivity <avi@qumranet.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Chris Wright <chrisw@sous-sol.org>,
virtualization@lists.osdl.org, Ingo Molnar <mingo@elte.hu>
Subject: Re: [RFC/PATCH LGUEST X86_64 00/13] Lguest for the x86_64
Date: Fri, 09 Mar 2007 13:20:33 +0200 [thread overview]
Message-ID: <45F14301.9090007@qumranet.com> (raw)
In-Reply-To: <1173399509.32234.61.camel@localhost.localdomain>
Rusty Russell wrote:
>> To prevent a guest from stealing all the hosts memory pages, we can
>> use these hashes to also limit the number of puds, pmds, and ptes.
>>
>> If the page is not pinned (currently used), we can set up LRU lists,
>> and find those pages that are somewhat stale, and free them. This
>> can be done safely since we have all the info we need to put them
>> back if the guest needs them again.
>>
>
> This is the same issue with 32-bit (one main reason why it's root-only).
> In my case it's not too hard to add a shrinker (it would drop PTE pages
> out of the pagetable of any non-running guest, just needs locking), but
> we also want to avoid pinning in guest (ie. userspace) pages: for this I
> think we really want a per-mm callback when the swapper wants to kick
> something out.
>
> I imagine kvm will have the same or similar issues (they restrict their
> pagetables to 256 pages per guest, which is simultanously too many and
> too few IMHO).
>
We have similar issues, but they are easily fixed since at most four
pages are pinned per vcpu (sixteen with Ingo's cr3 cache). A per-mm
swapper callback sounds great, especially when thinking about swapping
regular guest pages, and even more in the context of nested page tables.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
prev parent reply other threads:[~2007-03-09 11:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-08 17:38 [RFC/PATCH LGUEST X86_64 00/13] Lguest for the x86_64 Steven Rostedt
2007-03-09 0:18 ` Rusty Russell
2007-03-09 11:20 ` Avi Kivity [this message]
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=45F14301.9090007@qumranet.com \
--to=avi@qumranet.com \
--cc=chrisw@sous-sol.org \
--cc=mingo@elte.hu \
--cc=rusty@rustcorp.com.au \
--cc=virtualization@lists.osdl.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.