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 <[email protected]>
> Signed-off-by: Avi Kivity <[email protected]>
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
