Re: [kvm-ppc-devel] RFC/patch portability: split kvm_vm_ioctl v2

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Carsten Otte wrote:
> 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.

I was talking about x86.

On x86, you need contiguous userspace, contiguous guest, but again, 
what's the problem with one memory slot?


>
>> 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.

So would the current memory slot thing, no?

-- 
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/