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

[Zhang, X. <xia...@in...>]

Avi Kivity wrote:
> Zhang, Xiantao wrote:
>> Avi Kivity wrote:
>>=20
>>> Zhang, Xiantao wrote:
>>>=20
>>>> Zhang, Xiantao wrote:
>>>>=20
>>>>=20
>>>>>> Hi Avi,
>>>>>> 	So you mean IA64 can adopt the similar method as well?
>>>>>>=20
>>>>>>=20
>>>>=20
>>>>> What method do you mean exactly?
>>>>>=20
>>>>>=20
>>>> Put all arch-specific files into arch/ia64/kvm as you described in
>>>> future KVM infrastructure.=20
>>>>=20
>>>>=20
>>>>> 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/*/.
>>>>>=20
>>>>>=20
>>>> 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!=20
>>>>=20
>>>>=20
>>> ia64/ subdirectory is also fine.
>>>=20
>>=20
>> 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?=20
>>=20
>=20
> 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 ?
>=20
> 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=20
Xiantao