Carsten Otte wrote: > Carsten Otte wrote: > >> That's why memory allocation/preparation needs to be arch dependent: >> i386 needs a memory layout different from userspace page table due to >> your argument, and s390 needs to use the userspace page table due to >> hardware features we want to exploit. >> As Xiantao pointed out, x86 and ia64 can share the same memory setup >> code. But s390 and ppc don't. Therefore, I vote for putting it into >> x86 for now, and come up with an approach to share between x86 and >> ia64 later on. >> > After reading Izik's idea: Maybe we should go Izik's way, and have an > i386 special case that we can deprecate later on? > >
I don't really see a big difference between what we have now (sparse userspace, sparse guest) and Izik's idea (contiguous userspace, sparse guest). In both cases you need something like memory slots to describe the different sections. Moreover, on x86 you may want different properties for different sections (4K pages for the framebuffer, large pages for main memory), so you can't allocate memory in one big chunk. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
