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

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 3287 bytes --]

Zhang, Xiantao wrote:
> Hi Avi,
> 	Sound good! But what can we do before the merge? You know, we have to spend much effort maintaining our patches with sync with upstream tree. Do you have an interim solution or proposal for merging IA64 code?  Thanks. 
> Xiantao 
>   

The merge is due in a few weeks. If that is too far, we can push the x86
parts to arch/i386 and do makefile magic so that x86-64 sees it too.


> -----Original Message-----
> From: Avi Kivity [mailto:avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org] 
> Sent: 2007年9月27日 17:19
> To: Zhang, Xiantao
> Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org; virtualization
> Subject: Re: [RFC] KVM Source layout Proposal to accommodate new CPU architecture
>
> Zhang, Xiantao wrote:
>   
>> Hi Folks,
>> 	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. Attached foil describes the detail. With our proposal, we
>> can boot x86 guests based on commit
>> 2e278972a11eb14f031dea242a9ed118adfa0932, also didn't see regressions.
>> For IA64 side, we are rebasing our code to this framework. 
>> Main changes to current source:
>> 1. Add subdirectories, such as x86 and ia64 to hold arch-specific code.
>> 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
>> 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.
>> BTW, Userspace code changes are not involved in this thread. 
>> Considering the readability, we didn't attach the diff file in the mail,
>> due to big changes to kvm source structure, and only post the tarball
>> including whole directory "drivers/kvm" instead. For comparison, I
>> attached kvm_main.diff as well. 
>>
>> Any comments are appreciated from you! Hope to see IA64 support on KVM
>> earlier!
>>   
>>     
>
> The whole drivers/kvm/ thing was just a trick to get merged quickly.  I
> think the new layout should be something like
>
>   virt/kvm/, include/linux/kvm*.h -> common code
>   virt/lguest/ -> the other hypervisor
>   virt/virtio/ -> shared I/O infrastructure
>   virt/ -> the CONFIG_VIRTIALIZATION menu
>   arch/x86/kvm/, include/asm-x86/ -> x86 specific code
>   arch/ia64/kvm/, include/asm-ia64/ -> ia64 specific code
>
> etc.
>
> Of course, this depends on the x86 merge which is scheduled for early
> 2.6.24.
>
>   


-- 
Any sufficiently difficult bug is indistinguishable from a feature.



[-- Attachment #2: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #3: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel