linux-kernel - Re: [PATCH 6/13] KVM: memory slot management

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 27 Oct 2006 00:44:31 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Avi Kivity <avi@...ranet.com>
Cc:	linux-kernel@...r.kernel.org, kvm-devel@...ts.sourceforge.net
Subject: Re: [PATCH 6/13] KVM: memory slot management

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@...ranet.com>
> Signed-off-by: Avi Kivity <avi@...ranet.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 <><
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/