Hi Avi,
        So you mean IA64 can adopt the similar method as well? But even so, I 
am still thinking we have to come out a solution for checking IA64 code into 
existing KVM upstream tree , because KVM infrastructure in mainline Linux may 
been a long way to go. Moreover, we also have no method to avoid the 
abstraction for existing code to support cross-architecture framework before 
what you pointed gets happen. For example, kvm_main.c is also required to split 
as common interface for all architectures. So, I think it has no big conflicts 
between our proposal and the final KVM infrastructure in mainline Linux. How 
about your ideas? :)
Thanks 
Xiantao 

-----Original Message-----
From: Avi Kivity [mailto:[EMAIL PROTECTED] 
Sent: 2007年9月28日 22:46
To: Zhang, Xiantao
Cc: kvm-devel@lists.sourceforge.net; virtualization
Subject: Re: [RFC] KVM Source layout Proposal to accommodate new CPU 
architecture

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:[EMAIL PROTECTED] 
> Sent: 2007年9月27日 17:19
> To: Zhang, Xiantao
> Cc: kvm-devel@lists.sourceforge.net; 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.

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

Reply via email to