From: Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
To: kvm-devel <kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
Subject: large page support for kvm
Date: Tue, 29 Jan 2008 19:20:12 +0200 [thread overview]
Message-ID: <479F604C.20107@qumranet.com> (raw)
The npt patches started me thinking on large page support (2MB/4MB
pages), and I think we can implement them even when npt/ept are not
available.
Here's a rough sketch of my proposal:
- For every memory slot, allocate an array containing one int for every
potential large page included within that memory slot. Each entry in
the array contains the number of write-protected 4KB pages within the
large page frame corresponding to that entry.
For example, if we have a memory slot for gpas 1MB-1GB, we'd have an
array of size 511, corresponding to the 511 2MB pages from 2MB upwards.
If we shadow a pagetable at address 4MB+8KB, we'd increment the entry
corresponding to the large page at 4MB. When we unshadow that page,
decrement the entry.
- If we attempt to shadow a large page (either a guest pse pte, or a
real-mode pseudo pte), we check if the host page is a large page. If
so, we also check the write-protect count array. If the result is zero,
we create a shadow pse pte.
- Whenever we write-protect a page, also zap any large-page mappings for
that page. This means rmap will need some extension to handle pde rmaps
in addition to pte rmaps.
- qemu is extended to have a command-line option to use large pages to
back guest memory.
Large pages should improve performance significantly, both with
traditional shadow and npt/ept. Hopefully we will have transparent
Linux support for them one day.
--
error compiling committee.c: too many arguments to function
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
next reply other threads:[~2008-01-29 17:20 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-29 17:20 Avi Kivity [this message]
[not found] ` <479F604C.20107-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2008-01-30 18:40 ` large page support for kvm Joerg Roedel
[not found] ` <20080130184035.GS6960-5C7GfCeVMHo@public.gmane.org>
2008-01-31 5:44 ` Avi Kivity
2008-02-11 15:49 ` Marcelo Tosatti
2008-02-12 11:55 ` Avi Kivity
2008-02-13 0:15 ` Marcelo Tosatti
2008-02-13 6:45 ` Avi Kivity
2008-02-14 23:17 ` Marcelo Tosatti
2008-02-15 7:40 ` Roedel, Joerg
2008-02-17 9:38 ` Avi Kivity
2008-02-19 20:37 ` Marcelo Tosatti
2008-02-20 14:25 ` Avi Kivity
2008-02-22 2:01 ` Marcelo Tosatti
2008-02-22 7:16 ` 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=479F604C.20107@qumranet.com \
--to=avi-atkuwr5tajbwk0htik3j/w@public.gmane.org \
--cc=kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@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.