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

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

Zhang, Xiantao wrote:
> Hollis Blanchard wrote:
>   
>> 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?
>>     
>
> Due to big changes to current source structure, maybe a new branch would
> help to work, and doesn't
> impact existing quality of KVM.  If it is convenient for you to submit
> patches directly, also we are glad to do in that way.
>   

A branch with such large changes quickly becomes out-of-date, so it's 
best to send patches.

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


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