Avi Kivity wrote: > Zhang, Xiantao wrote: >> 2. kvm_x86_ops-kvm_ops.patch. In order to adapt different >> architectures, we have to change it to an neutral name. kvm_ops maybe >> not the best name, but shouldn't introduce different meanings. In the >> third patch, we add a sub field struct kvm_arch_ops for arch-specific >> ops. That is, different CPU archs can define its arch-specific >> ops for its special need. IMO, we should treat x86, IA64, ppc etc as >> different archtiectures, other than see vmx, svm as different archs. >> svm and vmx should be two different virtualization approaches for >> x86 arch from the point view of platforms. >> > > ia64, ppc, and s390 don't need to select an implementation at runtime > (since each have just one instruction set) so they don't need function > pointers. Instead we should use linkage (different functions for each > arch, but with the same names). Kbuild will select the right files to > compile depending on arch.
For x86 side, how to handle the co-existence of vmx and svm ? For example, in a release linux kernel which supports KVM, how to know it will be installed to Intel or AMD platforms ? If we determin it in advance, we have to compile them all in at one time, but it maybe difficult for current kvm code to implement. >> 3. re-frame.patch. This patch is the main work to to support >> differnt architectures. it includes: (1). Split kvm_main.c to >> kvm_arch.c and new kvm_main.c. kvm_arch.c under x86 directory >> contains arch-specific code, and new kvm_main.c only holds >> interfaces with user space, and basic kvm infrastructure. Split >> some functions to make them arch-independent. (2) Add an include >> directory to hold head files, and split kvm.h to two parts. One is >> kvm_arch.h to deposit some arch-specfic structures, such as struct >> kvm_vcpu_arch, kvm_arch_ops etc, some arch-dependent macros and >> functions declares. (3) Add arch support for structure kvm_ops, and >> structure kvm_vcpu. (4) Make file change. >> > > This is all too big. Carsten's approach (one thing at a time) is > better since it allows easy review of what is happening. OK. If we have consistent ideas for ultimate layouts, it should be easy to do. Thank you for your comments. Xiantao ------------------------------------------------------------------------- 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
