Re: RFC/patch portability: split kvm_vm_ioctl

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

Anthony Liguori wrote:
>> While the pic/apic related functions are obviously x86 specific, some
>> other ioctls seem to be common at a first glance.
>> KVM_SET_(USER)_MEMORY_REGION for example. We've got a total different
>> address layout on s390: we cannot support multiple slots, and a user
>> memory range always equals the guest physical memory [guest_phys + vm
>> specific offset = host user address]. We don't have nor need dedicated
>> vmas for the guest memory, we just use what the memory managment has in
>> stock. This is true, because we reuse the page table for user and guest
>> mode.
>>   
> 
> You still need to tell the kernel about vm specific offset right?  So 
> doesn't KVM_SET_USER_MEMORY_REGION for you just become that?  There's 
> nothing wrong with s390 not supporting multiple memory slots, but 
> there's no reason the ioctl interface can't be the same.

I've though about that too. The thing is, the interface would really 
do something different on s390. I think it's more confusing to 
userland to have one interface that does two different things 
depending on the architecture rather then having different interfaces 
for different things.
You're right that KVM_SET_USER_MEMORY_REGION would cover our needs if 
we return -EINVAL in case slot != 0 or guest start address != 0. I'll 
talk it though with Martin on monday.

Carsten



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