Re: RFC/patch portability: split kvm_vm_ioctl

[Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>]

Carsten Otte wrote:
> This patch splits kvm_vm_ioctl into archtecture independent parts, and
> x86 specific parts which go to kvm_arch_vcpu_ioctl in x86.c. 
>
> Common ioctls for all architectures are:
> KVM_CREATE_VCPU, KVM_GET_DIRTY_LOG
>
> I'd really like to see more commonalities, but all others did not fit
> our needs. I would love to keep KVM_GET_DIRTY_LOG common, so that the
> ingenious migration code does not need to care too much about different
> architectures.
>
> x86 specific ioctls are:
> KVM_SET_MEMORY_REGION, KVM_SET_USER_MEMORY_REGION,
> KVM_GET/SET_NR_MMU_PAGES, KVM_SET_MEMORY_ALIAS, KVM_CREATE_IRQCHIP,
> KVM_CREATE_IRQ_LINE, KVM_GET/SET_IRQCHIP
>
> 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.

Regards,

Anthony Liguori

> Looks to me like the s390 might have a lot in common with a future AMD
> nested page table implementation. If AMD choose to reuse the page table
> too, we might share the same ioctl to set up guest addressing with them.
>
> signed-off-by: Carsten Otte <cotte-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
> reviewed-by: Christian Borntraeger <borntraeger-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
> reviewed-by: Christian Ehrhardt <ehrhardt-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
> ---
>   


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