> Zhang, Xiantao wrote: > We are working on enabling KVM support on IA64 platform, and now > Linux, Windows guests get stable run and achieve reasonable performance > on KVM with Open GFW. But you know, the current KVM only considers x86 > platform, and is short of cross-architecture framework. Currently, we > have a proposal for KVM source layout to accommodate new CPU > architectures. That's great. I agree that general restructure of current x86 code is needed to fit different archs proper. I do strongly appreciate your efforts towards this.
> 1. Add subdirectories, such as x86 and ia64 to hold arch-specific code. I would prefer Avis move to /virt prior to that. But then we'll need arch specific subdirectories. I think they should go to /arch/<arch>/kvm. That would involve the architecure maintainers, which gives us more peer review. > 2. Split kvm_main.c to two parts. One is still called kvm_main.c, just > contains KVM common interfaces with user space, and basic KVM > infrastructure. The other one is named as kvm_arch.c under sub-directory > (eg. X86, ia64 etc), which includes arch-specific code to supplement the > functionality of kvm_main.c I disagree with the split you've made. I think we should try to keep as much as possible common, rather then just duplicating the efforts for each architecture we have. Thus, I do prefer to refine a clean architecutre backend interface based on the current vmx/svm split. We just need to move x86 specifics to a "kvm-x86" library, on which kvm-intel, kvm-amd and maybe kvm-rusty do depend. Interfacing to there needs to go via the same function vector we use for svm/vmx today. > 3. Add an "include" directory in drivers/kvm. Due to possibly complex > code logic in KVM source, maybe many header files need to maintain for > some architectures. If we put them under top-level include/asm-arch > directory, it may introduce much more maintain effort. So, we put it > under "drivers/kvm", and let it be effective when kernel configuration > time. To me, they clearly belong to include/arch. so long, Carsten ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
