Avi Kivity wrote: > 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. We don't on s390: we receive a page fault by the guest once it accesses a sparse hole in its address space. We check the user space's VMA and either page it in or submit an addressing exception to the guest.
> 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. That's right. On s390, we can live with whatever properties a section has with regard to page size, backing device and such. So memory may well come to live by different alloations, and different allocation methods. All we need is a permanent contiguous mapping of the guest physical addresses to host user addresses. So Izik's idea would work for us even if we have different sections. ------------------------------------------------------------------------- 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