Re: RFC/patch portability: split kvm_vm_ioctl

Carsten Otte
2007-10-13T07:31:22Z

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