Re: RFC/patch portability: split kvm_vm_ioctl

[Carsten Otte <cotte-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>]

Zhang, Xiantao wrote:
> I don't know why we not put KVM_SET_MEMORY_REGION,
> KVM_SET_USER_MEMORY_REGION as common, although 
> I have read the reasons you listed. I think they should work for most of
> archs, although it is not very friendly with s390.  If we put them 
> as arch-specific ones, we have to  duplicate many copies for them in KVM
> code. 
On s390, we use regular userspace memory to back our guest. Our 
architecture allows us to specify an offset and an address limit for 
the guest, and we don't need to have shaddow page tables and other 
tricks. We just use the userspace page table, and the guest memory is 
swapable to disk.

> One suggestion:  Maybe we can comment out current memory allocation
> logic in userspace for S390, and s390 use your apporach to get its
> memory.
Userspace will definetly need to do a special case for setting up the 
guest memory anyway due to major architectural differences. Thus I 
think it is fair to let it use two different ioctls for each case.


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