Re: RFC/patch portability: split kvm_vm_ioctl

Zhang, Xiantao
2007-10-13T04:08:30Z

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

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.

One suggestion: Maybe we can comment out current memory allocation
logic in userspace for S390, and s390 use your apporach to get its
memory.

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

>
------------------------------------------------------------------------
-
> 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-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/kvm-devel