Carsten Otte wrote: >> 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.
This maybe a long way to go. For current deveploment, maybe we should focus on exsiting code structure and make it accommodate new architectures, althoug future virtualization architecture maybe provided and looks attractive by mainline Linux kernel. > >> 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. Actually, we kept them as common parts as many as possible. In this process, maybe some functions is very hard to split due to its close relationsship with x86 side, and we just put it in kvm_arch.c first. Maybe can refine them in future arch-merge. >> 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. Agree, but it may introduce some maintain effort, if many kvm-specific files were all put under include/arch directory. > 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
