All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Avi Kivity <avi@qumranet.com>
Cc: linux-kernel@vger.kernel.org, kvm-devel@lists.sourceforge.net
Subject: Re: [PATCH 6/13] KVM: memory slot management
Date: Fri, 27 Oct 2006 00:44:31 +0200	[thread overview]
Message-ID: <200610270044.31382.arnd@arndb.de> (raw)
In-Reply-To: <20061026172756.D0649A0209@cleopatra.q>

On Thursday 26 October 2006 19:27, Avi Kivity wrote:
> kvm defines memory in "slots", more or less corresponding to the DIMM
> slots.
>
> this allows us to:
>  - avoid the VGA hole at 640K
>  - add a pci framebuffer at runtime
>  - hotplug memory
>
> Signed-off-by: Yaniv Kamay <yaniv@qumranet.com>
> Signed-off-by: Avi Kivity <avi@qumranet.com>

To bring up the discussion about guest memory allocation again,
I'd like to make a case for using defining guest real memory
as host user, not a special in-kernel address space.

You're probably aware of many of these points, but I'd like
to list all that I can think of, in case you haven't thought
of them:

- no need to preallocate memory that the guest doesn't actually use.
- guest memory can be paged to disk.
- you can mmap files into multiple guest for fast communication
- you can use mmap host files as backing store for guest blockdevices,
  including ext2 with the -o xip mount option to avoid double paging
- you can mmap packet sockets or similar to provide virtual networking
  devices.
- you can use hugetlbfs inside of guests
- you can mmap simple devices (e.g. frame buffer) directly into
  trusted guests without HW emulation.
- you can use gdb to debug the running guest address space
- no need for ioctl to access or allocate guest memory
- you can mmap a kernel image (MAP_PRIVATE) into multiple guests
  and share instruction cache lines.
- the kernel code doesn't need special accessors, but can use
  asm/uaccess.h.
- may be able to avoid a bunch of TLB flushes with nested page tables.

On the downside, I can see these points:

- As you mentioned guest size on 32 bit hosts is limited to around 1G.
- you probably have to rewrite your virtual MMU from scratch
- for optimal performance, pageable guests need something like the s390
  pagex/pfault mechanism in the guest kernel.
- if you want a guest not to be paged out, you need privileges to do mlock.
- you can't use swap space in the guest if you want to avoid the
  double paging problem (host needs to read a page from disk for the guest
  to swap it out), or you'd have to implement a mechanism like Martin
  Schwidefsky's page hints (cmm2) for s390.

	Arnd <><

  reply	other threads:[~2006-10-26 22:44 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-26 17:19 [PATCH 0/13] KVM: Kernel-based Virtual Machine (v3) Avi Kivity
2006-10-26 17:22 ` [PATCH 1/13] KVM: userspace interface Avi Kivity
     [not found]   ` <200610270051.43477.arnd@arndb.de>
2006-10-27  5:51     ` Avi Kivity
2006-10-26 17:23 ` [PATCH 2/13] KVM: Intel virtual mode extensions definitions Avi Kivity
2006-10-26 17:24 ` [PATCH 3/13] KVM: kvm data structures Avi Kivity
2006-10-26 22:55   ` Arnd Bergmann
2006-10-27  5:53     ` Avi Kivity
2006-10-27  7:39       ` Arnd Bergmann
2006-10-26 17:25 ` [PATCH 4/13] KVM: random accessors and constants Avi Kivity
2006-10-26 17:26 ` [PATCH 5/13] KVM: virtualization infrastructure Avi Kivity
2006-10-26 17:27 ` [PATCH 6/13] KVM: memory slot management Avi Kivity
2006-10-26 22:44   ` Arnd Bergmann [this message]
2006-10-27  5:47     ` Avi Kivity
2006-10-27  7:37       ` Arnd Bergmann
2006-10-27 13:26         ` Avi Kivity
2006-10-27 14:05           ` Arnd Bergmann
2006-10-29  9:10             ` Avi Kivity
2006-10-29  9:10               ` Avi Kivity
2006-10-27 15:43           ` [kvm-devel] " Anthony Liguori
2006-10-29  9:15             ` Avi Kivity
2006-10-29  9:15               ` Avi Kivity
2006-10-26 17:28 ` [PATCH 7/13] KVM: vcpu creation and maintenance Avi Kivity
2006-10-26 17:29 ` [PATCH 8/13] KVM: vcpu execution loop Avi Kivity
2006-10-26 17:30 ` [PATCH 9/13] KVM: define exit handlers Avi Kivity
2006-10-26 17:31 ` [PATCH 10/13] KVM: less common " Avi Kivity
2006-10-26 17:32 ` [PATCH 11/13] KVM: mmu Avi Kivity
2006-10-26 17:33 ` [PATCH 12/13] KVM: x86 emulator Avi Kivity
2006-10-26 17:34 ` [PATCH 13/13] KVM: plumbing Avi Kivity
  -- strict thread matches above, loose matches on Subject: below --
2006-10-23 13:28 [PATCH 0/7] KVM: Kernel-based Virtual Machine (v2) Avi Kivity
2006-10-23 13:30 ` [PATCH 6/13] KVM: memory slot management 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=200610270044.31382.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=avi@qumranet.com \
    --cc=kvm-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.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.