Re: [RFC] KVM Source layout Proposal to accommodate new CPU architecture

Zhang, Xiantao
2007-09-30T02:26:34Z

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