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

Reply via email to