[Patch] [0/3] Patches to support new architectures.

[Patch] [0/3] Patches to support new architectures.

[Zhang, Xiantao]

Hi all, 
Per our privious discussions about source layout, I just worked out
these patches to support new CPU archs for KVM. 
Firslty, we just move all files to its final position in source
structure as we discussed before.  In the drivers/kvm directory
I add an x86 directory to hold x86 specific code, and also add an
include dir for managing header files.  Then, some structures, such as
kvm_vcpu, struct kvm_arch_ops(changed to kvm_ops) are extended  with an
sub field *arch to accommodate arch-specific data fields wtih different
architectures.
 
1. move_files.patch : Move all files to its final position in the soruce
structure. No any code logic changed.
2. kvm_x86_ops-kvm_ops.patch.  In order to adapt different
architectures, we have to change it to an neutral name. kvm_ops maybe
not the best name, but shouldn't introduce different meanings. In the
third patch, we add a sub field struct kvm_arch_ops for arch-specific
ops. That is, different CPU archs can define its arch-specific 
ops for its special need. IMO, we should treat x86, IA64, ppc etc as
different archtiectures, other than see vmx, svm as different archs. svm
and vmx should be two different virtualization approaches for x86 arch
from the point view of platforms. 
3. re-frame.patch. This patch is the main work to to support differnt
architectures. it includes:
(1). Split kvm_main.c to kvm_arch.c and new kvm_main.c. kvm_arch.c under
x86 directory contains arch-specific code, and new kvm_main.c only holds
interfaces with user space, and basic kvm infrastructure.  Split some
functions to make them arch-independent.
(2) Add an include directory to hold head files, and split kvm.h to two
parts. One is kvm_arch.h to deposit some arch-specfic structures, such
as struct kvm_vcpu_arch, kvm_arch_ops etc, some arch-dependent macros
and functions declares. 
(3) Add arch support for structure kvm_ops, and structure kvm_vcpu. 
(4) Make file change.

By the way, maybe more changes are needed in furture when real new
architecture in. Perhaps, some current arch-independent code today will
be thought as arch-specific ones, vice versa.  Anyway, we these changes
are basically necessary for our re-frame work. Only these changes in,
then we can carry out further work. 

These patches are based on commit
7060e1c92b504ac725e2ffbc91053c1dc684e685(last commit of Oct 8).

Due to big changes to code structure, these pathes will be out of date
soon. So, we have to make the desicion ASAP, or it is very painful to
rebase them. 

Basically, these patches have no more code logic and functionality
changes. And I have tested them on our platforms. Works well on 32bit
and 64bit platforms. 

Todo List: split include/linux/kvm.h & kvm_para.h(Not urgent until real
other archs in.). 
                Userspace compile infrastructure change accordingly. 

Any comments are welcome!  

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

Re: [Patch] [0/3] Patches to support new architectures.

[Carsten Otte]

Zhang, Xiantao wrote:
> These patches are based on commit
> 7060e1c92b504ac725e2ffbc91053c1dc684e685(last commit of Oct 8).
They don't apply on top of git head anymore, could you please rebase?

> Any comments are welcome!  
I do appreciate your work towards portability. Could you also please 
post the patches inline, so that we can reply and comment on the code? 
  Could you please try to split your patches into small reviewable 
patches?

thanks,
Carsten

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

Re: [Patch] [0/3] Patches to support new architectures.

[Zhang, Xiantao]

Carsten Otte wrote:
> Zhang, Xiantao wrote:
>> These patches are based on commit
>> 7060e1c92b504ac725e2ffbc91053c1dc684e685(last commit of Oct 8).
> They don't apply on top of git head anymore, could you please rebase?
> 
>> Any comments are welcome!
> I do appreciate your work towards portability. Could you also please
> post the patches inline, so that we can reply and comment on the code?
>   Could you please try to split your patches into small reviewable

Thanks.  put them inline. What the first patch did is moving files, so
don't put them inline
and just put generated comments in. 
thanks, Xiantao


> thanks,
> Carsten
> 
>
------------------------------------------------------------------------
-
> 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-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/kvm-devel

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

Re: [Patch] [0/3] Patches to support new architectures.

[Avi Kivity]

Zhang, Xiantao wrote:
> 2. kvm_x86_ops-kvm_ops.patch.  In order to adapt different
> architectures, we have to change it to an neutral name. kvm_ops maybe
> not the best name, but shouldn't introduce different meanings. In the
> third patch, we add a sub field struct kvm_arch_ops for arch-specific
> ops. That is, different CPU archs can define its arch-specific 
> ops for its special need. IMO, we should treat x86, IA64, ppc etc as
> different archtiectures, other than see vmx, svm as different archs. svm
> and vmx should be two different virtualization approaches for x86 arch
> from the point view of platforms. 
>   

ia64, ppc, and s390 don't need to select an implementation at runtime 
(since each have just one instruction set) so they don't need function 
pointers.  Instead we should use linkage (different functions for each 
arch, but with the same names).  Kbuild will select the right files to 
compile depending on arch.


> 3. re-frame.patch. This patch is the main work to to support differnt
> architectures. it includes:
> (1). Split kvm_main.c to kvm_arch.c and new kvm_main.c. kvm_arch.c under
> x86 directory contains arch-specific code, and new kvm_main.c only holds
> interfaces with user space, and basic kvm infrastructure.  Split some
> functions to make them arch-independent.
> (2) Add an include directory to hold head files, and split kvm.h to two
> parts. One is kvm_arch.h to deposit some arch-specfic structures, such
> as struct kvm_vcpu_arch, kvm_arch_ops etc, some arch-dependent macros
> and functions declares. 
> (3) Add arch support for structure kvm_ops, and structure kvm_vcpu. 
> (4) Make file change.
>   

This is all too big.  Carsten's approach (one thing at a time)  is 
better since it allows easy review of what is happening.



-- 
error compiling committee.c: too many arguments to function


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

Re: [Patch] [0/3] Patches to support new architectures.

[Zhang, Xiantao]

Avi Kivity wrote:
> Zhang, Xiantao wrote:
>> 2. kvm_x86_ops-kvm_ops.patch.  In order to adapt different
>> architectures, we have to change it to an neutral name. kvm_ops maybe
>> not the best name, but shouldn't introduce different meanings. In the
>> third patch, we add a sub field struct kvm_arch_ops for arch-specific
>> ops. That is, different CPU archs can define its arch-specific
>> ops for its special need. IMO, we should treat x86, IA64, ppc etc as
>> different archtiectures, other than see vmx, svm as different archs.
>> svm and vmx should be two different virtualization approaches for
>> x86 arch from the point view of platforms.
>> 
> 
> ia64, ppc, and s390 don't need to select an implementation at runtime
> (since each have just one instruction set) so they don't need function
> pointers.  Instead we should use linkage (different functions for each
> arch, but with the same names).  Kbuild will select the right files to
> compile depending on arch.

For x86 side, how to handle the co-existence of vmx and svm ?  For
example,  in a release linux kernel which supports KVM,  how to know it 
will be installed to Intel or AMD platforms ? If we determin it in
advance,  we have to compile them all in at one time, but it maybe
difficult for current 
kvm code to implement. 
 
>> 3. re-frame.patch. This patch is the main work to to support
>> differnt architectures. it includes: (1). Split kvm_main.c to
>> kvm_arch.c and new kvm_main.c. kvm_arch.c under x86 directory
>> contains arch-specific code, and new kvm_main.c only holds
>> interfaces with user space, and basic kvm infrastructure.  Split
>> some functions to make them arch-independent. (2) Add an include
>> directory to hold head files, and split kvm.h to two parts. One is
>> kvm_arch.h to deposit some arch-specfic structures, such as struct
>> kvm_vcpu_arch, kvm_arch_ops etc, some arch-dependent macros and
>> functions declares. (3) Add arch support for structure kvm_ops, and
>> structure kvm_vcpu. (4) Make file change.  
>> 
> 
> This is all too big.  Carsten's approach (one thing at a time)  is
> better since it allows easy review of what is happening.

OK. If we have consistent ideas for ultimate layouts, it should be easy
to do. 

Thank you for your comments.  
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/

Re: [Patch] [0/3] Patches to support new architectures.

[Avi Kivity]

Zhang, Xiantao wrote:
> Avi Kivity wrote:
>   
>> Zhang, Xiantao wrote:
>>     
>>> 2. kvm_x86_ops-kvm_ops.patch.  In order to adapt different
>>> architectures, we have to change it to an neutral name. kvm_ops maybe
>>> not the best name, but shouldn't introduce different meanings. In the
>>> third patch, we add a sub field struct kvm_arch_ops for arch-specific
>>> ops. That is, different CPU archs can define its arch-specific
>>> ops for its special need. IMO, we should treat x86, IA64, ppc etc as
>>> different archtiectures, other than see vmx, svm as different archs.
>>> svm and vmx should be two different virtualization approaches for
>>> x86 arch from the point view of platforms.
>>>
>>>       
>> ia64, ppc, and s390 don't need to select an implementation at runtime
>> (since each have just one instruction set) so they don't need function
>> pointers.  Instead we should use linkage (different functions for each
>> arch, but with the same names).  Kbuild will select the right files to
>> compile depending on arch.
>>     
>
> For x86 side, how to handle the co-existence of vmx and svm ?  For
> example,  in a release linux kernel which supports KVM,  how to know it 
> will be installed to Intel or AMD platforms ? If we determin it in
> advance,  we have to compile them all in at one time, but it maybe
> difficult for current 
> kvm code to implement. 
>   

x86 will continue to use kvm_x86_ops for that purposes.  But other archs 
should not.

x86 will use both mechanisms: first, linkage will select the x86 
function, and then kvm_x86_ops will be used to select the implementation 
dependent code.  The two levels are very different as kvm_x86_ops is 
very low level and x86 specific.


-- 
error compiling committee.c: too many arguments to function


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

Re: [Patch] [0/3] Patches to support new architectures.

[Zhang, Xiantao]

Avi Kivity wrote:
> Zhang, Xiantao wrote:
>> Avi Kivity wrote:
>> 
>>> Zhang, Xiantao wrote:
>>> 
>>>> 2. kvm_x86_ops-kvm_ops.patch.  In order to adapt different
>>>> architectures, we have to change it to an neutral name. kvm_ops
>>>> maybe not the best name, but shouldn't introduce different
>>>> meanings. In the third patch, we add a sub field struct
>>>> kvm_arch_ops for arch-specific ops. That is, different CPU archs
>>>> can define its arch-specific 
>>>> ops for its special need. IMO, we should treat x86, IA64, ppc etc
>>>> as different archtiectures, other than see vmx, svm as different
>>>> archs. svm and vmx should be two different virtualization
>>>> approaches for x86 arch from the point view of platforms.
>>>> 
>>>> 
>>> ia64, ppc, and s390 don't need to select an implementation at
>>> runtime (since each have just one instruction set) so they don't
>>> need function pointers.  Instead we should use linkage (different
>>> functions for each arch, but with the same names).  Kbuild will
>>> select the right files to compile depending on arch. 
>>> 
>> 
>> For x86 side, how to handle the co-existence of vmx and svm ?  For
>> example,  in a release linux kernel which supports KVM,  how to know
>> it will be installed to Intel or AMD platforms ? If we determin it in
>> advance,  we have to compile them all in at one time, but it maybe
>> difficult for current kvm code to implement.
>> 
> 
> x86 will continue to use kvm_x86_ops for that purposes.  But other
> archs should not.
> 
> x86 will use both mechanisms: first, linkage will select the x86
> function, and then kvm_x86_ops will be used to select the
> implementation dependent code.  The two levels are very different as
> kvm_x86_ops is very low level and x86 specific.
Hi Avi,
     Maybe linkage is a better choice. But if we need to maintain two
different implmentation for different archs, it may introduce
unnecessary effort.
In addition, I can't figure out any disadvantages with function
pointers, moreover, it makes source uniform for all architectures,
though it is not very necessary. 
Thanks 
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/

Re: [Patch] [0/3] Patches to support new architectures.

[Avi Kivity]

Zhang, Xiantao wrote:
>>
>> x86 will continue to use kvm_x86_ops for that purposes.  But other
>> archs should not.
>>
>> x86 will use both mechanisms: first, linkage will select the x86
>> function, and then kvm_x86_ops will be used to select the
>> implementation dependent code.  The two levels are very different as
>> kvm_x86_ops is very low level and x86 specific.
>>     
> Hi Avi,
>      Maybe linkage is a better choice. But if we need to maintain two
> different implmentation for different archs, it may introduce
> unnecessary effort.
> In addition, I can't figure out any disadvantages with function
> pointers, moreover, it makes source uniform for all architectures,
> though it is not very necessary. 
>   

Linkage is more efficient (though I don't think we'll be able to measure
the difference) and is also the traditional way of doing things in Linux.

I don't see why it causes extra effort.  Can you explain?

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


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

Re: [Patch] [0/3] Patches to support new architectures.

[Zhang, Xiantao]

Avi Kivity wrote:
> Zhang, Xiantao wrote:
>>> 
>>> x86 will continue to use kvm_x86_ops for that purposes.  But other
>>> archs should not. 
>>> 
>>> x86 will use both mechanisms: first, linkage will select the x86
>>> function, and then kvm_x86_ops will be used to select the
>>> implementation dependent code.  The two levels are very different as
>>> kvm_x86_ops is very low level and x86 specific.
>>> 
>> Hi Avi,
>>      Maybe linkage is a better choice. But if we need to maintain two
>> different implmentation for different archs, it may introduce
>> unnecessary effort. In addition, I can't figure out any
>> disadvantages with function pointers, moreover, it makes source
>> uniform for all architectures, though it is not very necessary.
>> 
> 
> Linkage is more efficient (though I don't think we'll be able to
> measure the difference) and is also the traditional way of doing
> things in Linux. 
> 
> I don't see why it causes extra effort.  Can you explain?

I orgirnally mean we have to wrap all functions related to kvm_x86_ops.
But seems it doesn't introduce 
extra maintain effort, if other architectures implment these functions
directly.  Good method!

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

Re: [Patch] [0/3] Patches to support new architectures.

[Carsten Otte]

Zhang, Xiantao wrote:
> I orgirnally mean we have to wrap all functions related to kvm_x86_ops.
> But seems it doesn't introduce 
> extra maintain effort, if other architectures implment these functions
> directly.  Good method!
That was my idea at first too, until Hollis has beaten me up on this. 
Most archs don't have the split like vmx/svm do, and the compiler 
automagically inlines the wrapper for x86 which gets optimized away 
completely.

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