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/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
