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