Re: [kvm-devel] [RFC] KVM Source layout Proposal to accommodate new CPU architecture
Avi Kivity wrote: Zhang, Xiantao wrote: Avi Kivity wrote: Zhang, Xiantao wrote: Zhang, Xiantao wrote: Hi Avi, So you mean IA64 can adopt the similar method as well? What method do you mean exactly? Put all arch-specific files into arch/ia64/kvm as you described in future KVM infrastructure. The powerpc people had some patches to make kvm_main arch independent. We should work on that base. To avoid a dependency on the x86 merge, we can start by working withing drivers/kvm/, for example creating drivers/kvm/x86.c and drivers/kvm/ia64.c. Later patches can move these to arch/*/. It may work on x86 side. But for IA64, we have several source files and assembly files to implement a VMM module, which contains the virtualization logic of CPU, MMU and other platform devices. (In KVM forum, Anthony had presented IA64/KVM architecture which is a bit different with x86 side due to different approaches for VT.).If we put all such these arch-specific files in one directory, it looks very strange! ia64/ subdirectory is also fine. But even so , we have to split current code to be arch-independent, and to support IA64 and other architectures. So, why not add an more subdirectory x86 in drivers kvm to hold X86-arch code? Sure, that's not an issue. Could you help to open a branch from master tree for this work? We are very willing to contribute to it:) And it should also conform with with future infrastructure in Linux. Maybe we can borrow the idea from UML code structure. Do you think so ? Eventually I'd like to see the code in arch/*/kvm. That's probably not easily doable right now because modules cannot span directories, but once that's solved, we'll do that as this is most consistent with the rest of the kernel. Agree. Maybe we can investigate the issue at the same time. Xiantao - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] KVM Source layout Proposal to accommodate new CPU architecture
On Mon, 2007-10-08 at 10:36 +0800, Zhang, Xiantao wrote: Avi Kivity wrote: Zhang, Xiantao wrote: Avi Kivity wrote: Zhang, Xiantao wrote: Zhang, Xiantao wrote: Hi Avi, So you mean IA64 can adopt the similar method as well? What method do you mean exactly? Put all arch-specific files into arch/ia64/kvm as you described in future KVM infrastructure. The powerpc people had some patches to make kvm_main arch independent. We should work on that base. To avoid a dependency on the x86 merge, we can start by working withing drivers/kvm/, for example creating drivers/kvm/x86.c and drivers/kvm/ia64.c. Later patches can move these to arch/*/. It may work on x86 side. But for IA64, we have several source files and assembly files to implement a VMM module, which contains the virtualization logic of CPU, MMU and other platform devices. (In KVM forum, Anthony had presented IA64/KVM architecture which is a bit different with x86 side due to different approaches for VT.).If we put all such these arch-specific files in one directory, it looks very strange! ia64/ subdirectory is also fine. But even so , we have to split current code to be arch-independent, and to support IA64 and other architectures. So, why not add an more subdirectory x86 in drivers kvm to hold X86-arch code? Sure, that's not an issue. Could you help to open a branch from master tree for this work? We are very willing to contribute to it:) Do you really need a new branch? Why not just submit patches? -- Hollis Blanchard IBM Linux Technology Center - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] KVM Source layout Proposal to accommodate new CPU architecture
On Tue, 2007-10-02 at 14:11 +1000, Rusty Russell wrote: On Tue, 2007-10-02 at 01:19 +, Hollis Blanchard wrote: On Sun, 30 Sep 2007 15:56:16 +0200, Avi Kivity wrote: Eventually I'd like to see the code in arch/*/kvm. That's probably not easily doable right now because modules cannot span directories, but once that's solved, we'll do that as this is most consistent with the rest of the kernel. What is the spanning directories issue? Can't I build arch/powerpc/kvm/kvm-powerpc.ko and drivers/kvm/kvm.ko and let modprobe sort out the dependency? Sure, but it creates a silly module. Isn't there precedent in other areas? What about cpufreq or ALSA? (I'm really asking; don't have time to investigate further right now.) I think guest code belongs in arch/*/kvm/, but host code can be done as subdirs under drivers/kvm/. Funny, I would say the opposite. The host code is where I'm mucking with deep architectural state like stealing the TLB out from under Linux. The guest state is all what would a processor like this do? -- Hollis Blanchard IBM Linux Technology Center - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] KVM Source layout Proposal to accommodate new CPU architecture
On Tue, 2007-10-02 at 01:01 -0500, Hollis Blanchard wrote: On Tue, 2007-10-02 at 14:11 +1000, Rusty Russell wrote: On Tue, 2007-10-02 at 01:19 +, Hollis Blanchard wrote: On Sun, 30 Sep 2007 15:56:16 +0200, Avi Kivity wrote: Eventually I'd like to see the code in arch/*/kvm. That's probably not easily doable right now because modules cannot span directories, but once that's solved, we'll do that as this is most consistent with the rest of the kernel. What is the spanning directories issue? Can't I build arch/powerpc/kvm/kvm-powerpc.ko and drivers/kvm/kvm.ko and let modprobe sort out the dependency? Sure, but it creates a silly module. Isn't there precedent in other areas? What about cpufreq or ALSA? (I'm really asking; don't have time to investigate further right now.) Hmm, cpufreq does do something like this, so I guess it's a fair call. I think guest code belongs in arch/*/kvm/, but host code can be done as subdirs under drivers/kvm/. Funny, I would say the opposite. The host code is where I'm mucking with deep architectural state like stealing the TLB out from under Linux. The guest state is all what would a processor like this do? From my POV all platforms belong in arch/*/, and KVM just presents another platform. But the implementation of KVM is as much kvm-specific as arch-specific, so I can argue over that one. Whatever way we go, grouping both host and guest support in the same dir seems confusing (which is why lguest is moving to arch/i386/lguest/ for guest and drivers/lguest/i386/ for host). Cheers, Rusty. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] KVM Source layout Proposal to accommodate new CPU architecture
Rusty Russell wrote: Whatever way we go, grouping both host and guest support in the same dir seems confusing (which is why lguest is moving to arch/i386/lguest/ for guest and drivers/lguest/i386/ for host). That really is funny. Our s39host is just the other way round: arch/s390/sie for the host, and drivers/s390/sie for the guest. Maybe lguest is upside down cause it's from australia? But at least the argument of a clear separation between guest and host in the source tree seems to be common sense. Carsten - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] KVM Source layout Proposal to accommodate new CPU architecture
On Sun, 30 Sep 2007 15:56:16 +0200, Avi Kivity wrote: Eventually I'd like to see the code in arch/*/kvm. That's probably not easily doable right now because modules cannot span directories, but once that's solved, we'll do that as this is most consistent with the rest of the kernel. What is the spanning directories issue? Can't I build arch/powerpc/kvm/kvm-powerpc.ko and drivers/kvm/kvm.ko and let modprobe sort out the dependency? -- Hollis Blanchard IBM Linux Technology Center - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] KVM Source layout Proposal to accommodate new CPU architecture
On Tue, 2007-10-02 at 01:19 +, Hollis Blanchard wrote: On Sun, 30 Sep 2007 15:56:16 +0200, Avi Kivity wrote: Eventually I'd like to see the code in arch/*/kvm. That's probably not easily doable right now because modules cannot span directories, but once that's solved, we'll do that as this is most consistent with the rest of the kernel. What is the spanning directories issue? Can't I build arch/powerpc/kvm/kvm-powerpc.ko and drivers/kvm/kvm.ko and let modprobe sort out the dependency? Sure, but it creates a silly module. I think guest code belongs in arch/*/kvm/, but host code can be done as subdirs under drivers/kvm/. Cheers, Rusty. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] KVM Source layout Proposal to accommodate new CPU architecture
Zhang, Xiantao wrote: Zhang, Xiantao wrote: Hi Avi, So you mean IA64 can adopt the similar method as well? What method do you mean exactly? Put all arch-specific files into arch/ia64/kvm as you described in future KVM infrastructure. The powerpc people had some patches to make kvm_main arch independent. We should work on that base. To avoid a dependency on the x86 merge, we can start by working withing drivers/kvm/, for example creating drivers/kvm/x86.c and drivers/kvm/ia64.c. Later patches can move these to arch/*/. It may work on x86 side. But for IA64, we have several source files and assembly files to implement a VMM module, which contains the virtualization logic of CPU, MMU and other platform devices. (In KVM forum, Anthony had presented IA64/KVM architecture which is a bit different with x86 side due to different approaches for VT.).If we put all such these arch-specific files in one directory, it looks very strange! ia64/ subdirectory is also fine. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] KVM Source layout Proposal to accommodate new CPU architecture
Avi Kivity wrote: Zhang, Xiantao wrote: Zhang, Xiantao wrote: Hi Avi, So you mean IA64 can adopt the similar method as well? What method do you mean exactly? Put all arch-specific files into arch/ia64/kvm as you described in future KVM infrastructure. The powerpc people had some patches to make kvm_main arch independent. We should work on that base. To avoid a dependency on the x86 merge, we can start by working withing drivers/kvm/, for example creating drivers/kvm/x86.c and drivers/kvm/ia64.c. Later patches can move these to arch/*/. It may work on x86 side. But for IA64, we have several source files and assembly files to implement a VMM module, which contains the virtualization logic of CPU, MMU and other platform devices. (In KVM forum, Anthony had presented IA64/KVM architecture which is a bit different with x86 side due to different approaches for VT.).If we put all such these arch-specific files in one directory, it looks very strange! ia64/ subdirectory is also fine. But even so , we have to split current code to be arch-independent, and to support IA64 and other architectures. So, why not add an more subdirectory x86 in drivers kvm to hold X86-arch code? And it should also conform with with future infrastructure in Linux. Maybe we can borrow the idea from UML code structure. Do you think so ? Thanks Xiantao - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] KVM Source layout Proposal to accommodate new CPU architecture
Zhang, Xiantao wrote: Avi Kivity wrote: Zhang, Xiantao wrote: Zhang, Xiantao wrote: Hi Avi, So you mean IA64 can adopt the similar method as well? What method do you mean exactly? Put all arch-specific files into arch/ia64/kvm as you described in future KVM infrastructure. The powerpc people had some patches to make kvm_main arch independent. We should work on that base. To avoid a dependency on the x86 merge, we can start by working withing drivers/kvm/, for example creating drivers/kvm/x86.c and drivers/kvm/ia64.c. Later patches can move these to arch/*/. It may work on x86 side. But for IA64, we have several source files and assembly files to implement a VMM module, which contains the virtualization logic of CPU, MMU and other platform devices. (In KVM forum, Anthony had presented IA64/KVM architecture which is a bit different with x86 side due to different approaches for VT.).If we put all such these arch-specific files in one directory, it looks very strange! ia64/ subdirectory is also fine. But even so , we have to split current code to be arch-independent, and to support IA64 and other architectures. So, why not add an more subdirectory x86 in drivers kvm to hold X86-arch code? Sure, that's not an issue. And it should also conform with with future infrastructure in Linux. Maybe we can borrow the idea from UML code structure. Do you think so ? Eventually I'd like to see the code in arch/*/kvm. That's probably not easily doable right now because modules cannot span directories, but once that's solved, we'll do that as this is most consistent with the rest of the kernel. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] KVM Source layout Proposal to accommodate new CPU architecture
Avi Kivity wrote: Zhang, Xiantao wrote: Avi Kivity wrote: Zhang, Xiantao wrote: Zhang, Xiantao wrote: Hi Avi, So you mean IA64 can adopt the similar method as well? What method do you mean exactly? Put all arch-specific files into arch/ia64/kvm as you described in future KVM infrastructure. The powerpc people had some patches to make kvm_main arch independent. We should work on that base. To avoid a dependency on the x86 merge, we can start by working withing drivers/kvm/, for example creating drivers/kvm/x86.c and drivers/kvm/ia64.c. Later patches can move these to arch/*/. It may work on x86 side. But for IA64, we have several source files and assembly files to implement a VMM module, which contains the virtualization logic of CPU, MMU and other platform devices. (In KVM forum, Anthony had presented IA64/KVM architecture which is a bit different with x86 side due to different approaches for VT.).If we put all such these arch-specific files in one directory, it looks very strange! ia64/ subdirectory is also fine. But even so , we have to split current code to be arch-independent, and to support IA64 and other architectures. So, why not add an more subdirectory x86 in drivers kvm to hold X86-arch code? Sure, that's not an issue. Thanks, Maybe we should work together to make it happen earlier :) And it should also conform with with future infrastructure in Linux. Maybe we can borrow the idea from UML code structure. Do you think so ? Eventually I'd like to see the code in arch/*/kvm. That's probably not easily doable right now because modules cannot span directories, but once that's solved, we'll do that as this is most consistent with the rest of the kernel. Yeah, that should be an elegant solution in future, if module compilation can span directories. Thanks Xiantao - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] KVM Source layout Proposal to accommodate new CPU architecture
On Thu, 2007-09-27 at 11:18 +0200, Avi Kivity wrote: 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 The problem with this separation is that module source cannot span directories (at least, not that I could find). This is why lguest went for i386_ prefix for arch separation. Cheers, Rusty. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] KVM Source layout Proposal to accommodate new CPU architecture
Hi Rusty. On Sat, Sep 29, 2007 at 11:06:51PM +1000, Rusty Russell wrote: On Thu, 2007-09-27 at 11:18 +0200, Avi Kivity wrote: 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 The problem with this separation is that module source cannot span directories (at least, not that I could find). That's supported but not in the most elegant fashion. In your Makefile in the top-level directory just specify the relevant .o files in the subdirectories. So you would have: lguest-y := file.o lguest-y += dir/foo.o lguest-y += dir2/bar.o obj-$(CONFIG_...) := lguset.o If you have trouble making this work drop me a mail and I will try to help with a more specific example. Sam - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] KVM Source layout Proposal to accommodate new CPU architecture
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/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] KVM Source layout Proposal to accommodate new CPU architecture
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/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [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/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] KVM Source layout Proposal to accommodate new CPU architecture
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/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] KVM Source layout Proposal to accommodate new CPU architecture
Zhang, Xiantao wrote: Hi Avi, So you mean IA64 can adopt the similar method as well? What method do you mean exactly? 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? :) The powerpc people had some patches to make kvm_main arch independent. We should work on that base. To avoid a dependency on the x86 merge, we can start by working withing drivers/kvm/, for example creating drivers/kvm/x86.c and drivers/kvm/ia64.c. Later patches can move these to arch/*/. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] KVM Source layout Proposal to accommodate new CPU architecture
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 -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. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] KVM Source layout Proposal to accommodate new CPU architecture
Hi, is this the same layout introduced for the powerpc port ? Perhaps you should work together ? Laurent 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! Thanks Best Wishes Xiantao Intel Opensource Technology Center. * BLOCKED FILE ALERT!* The attachment '.kvm-intel.ko.cmd' has been blocked because it is a disallowed file type. The attachment has been replaced by this message. If you feel you have received this message in error and are an Intel employee, then please contact the Global Service Desk http://servicedesk.intel.com. More Information: If you are an Intel employee and internal to the Intel network, visit Secure Intel http://secure.intel.com/infosec/response_services/pc+and+network+protection/email+security/email+security.htm to learn more about E-mail attachment options. If you are not an Intel employee, please contact your Intel sponsor for additional information. http://it.intel.com Copyright © Intel Corporation, 2002-2006. All rights reserved. *Other names and brands may be claimed as the property of others. **Intel is not responsible for content of sites outside our intranet. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel -- - [EMAIL PROTECTED] -- Software is hard - Donald Knuth signature.asc Description: OpenPGP digital signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
