[PATCH 0/7][RFC] Enable kvm/ia-64 to build kvm components in userspace.

[PATCH 0/7][RFC] Enable kvm/ia-64 to build kvm components in userspace.

[Zhang, Xiantao]

Hi, Avi 
     This patchset intends to enable kvm/ia-64 to build kvm components
in userspace.  You know,  current userspace code only supports x86 to
build kvm components, but kvm/ia64 have to build kvm modules and qemu
separately.  In this way, it is not conveninent for user-ends, and kvm's
release package can't  include kvm/ia64 bits.   To make kvm userspace
more friendly and common, I re-organize the kernel directory of
kvm-userspace.git, and create two sub-directory (x86 and ia64)to hold
arch-specific source files. With its support, ia64's end-users can build
kvm/ia64 components in the same way with ia32 side, and future kvm's
release packages are also capable to include ia64 bits.  Appreicate any
review comments! 

PS:  To make it reviewable, I splited it into small patches. The first
five patches intends to move x86 specific files to x86 directory, the
sixth one for enabling Kbuild in new laylout. The last one makes
kvm/ia64 build components in userspace.  

Thanks 
Xiantao 

Re: [PATCH 0/7][RFC] Enable kvm/ia-64 to build kvm components in userspace.

[Avi Kivity]

Zhang, Xiantao wrote:
> Hi, Avi 
>      This patchset intends to enable kvm/ia-64 to build kvm components
> in userspace.  You know,  current userspace code only supports x86 to
> build kvm components, but kvm/ia64 have to build kvm modules and qemu
> separately.  In this way, it is not conveninent for user-ends, and kvm's
> release package can't  include kvm/ia64 bits.   To make kvm userspace
> more friendly and common, I re-organize the kernel directory of
> kvm-userspace.git, and create two sub-directory (x86 and ia64)to hold
> arch-specific source files. With its support, ia64's end-users can build
> kvm/ia64 components in the same way with ia32 side, and future kvm's
> release packages are also capable to include ia64 bits.  Appreicate any
> review comments! 
>
>   

While I have no objection in principle, I don't understand the 
motivation.  kvm ia64 cannot be retrofitted to older kernels (since some 
symbols are not exported).  Why is it not sufficient to use the kernel 
module from the kernel tree?

Eventually, the x86 external module support will be dropped as well.  
Most noncommercial distributions already have good kvm support; the only 
questions is what to do with RHEL/SLES/CentOs users -- wait until the 
next major release, or wait until ovirt starts shipping?

Note that mmu notifiers further reduce the attractiveness of the 
external module, unless someone manages to backport it to older kernels.

> PS:  To make it reviewable, I splited it into small patches. The first
> five patches intends to move x86 specific files to x86 directory, the
> sixth one for enabling Kbuild in new laylout. The last one makes
> kvm/ia64 build components in userspace.  
>   

Please generate patches with the '-M' option (or set the 'diff.renames' 
config option) so file movement patches show up as such.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

RE: [PATCH 0/7][RFC] Enable kvm/ia-64 to build kvm components in userspace.

[Zhang, Xiantao]

Avi Kivity wrote:
> Zhang, Xiantao wrote:
>> Hi, Avi
>>      This patchset intends to enable kvm/ia-64 to build kvm
>> components in userspace.  You know,  current userspace code only
>> supports x86 to build kvm components, but kvm/ia64 have to build kvm
>> modules and qemu separately.  In this way, it is not conveninent for
>> user-ends, and kvm's release package can't  include kvm/ia64 bits.  
>> To make kvm userspace more friendly and common, I re-organize the
>> kernel directory of kvm-userspace.git, and create two sub-directory
>> (x86 and ia64)to hold arch-specific source files. With its support,
>> ia64's end-users can build kvm/ia64 components in the same way with
>> ia32 side, and future kvm's release packages are also capable to
>> include ia64 bits.  Appreicate any review comments! 
>> 
>> 
> 
> While I have no objection in principle, I don't understand the
> motivation.  kvm ia64 cannot be retrofitted to older kernels (since
> some symbols are not exported).  Why is it not sufficient to use the
> kernel module from the kernel tree?

The motivation is that developers and testers have to upgrade their
kernels if kernel's minor version changed, otherwise the module formats
would be incompatible.  Especially it is not convenient for some auto
testing systems, because the upgrading kernel process would be more
complex.  In addition,  we can't alwasys require the end-users to use
the lastest kvm.git bits as host kernels, especially for servers which
may disallow to do a restart after enabling  kvm on it. 


> Eventually, the x86 external module support will be dropped as well.
> Most noncommercial distributions already have good kvm support; the
> only questions is what to do with RHEL/SLES/CentOs users -- wait
> until the next major release, or wait until ovirt starts shipping?


> Note that mmu notifiers further reduce the attractiveness of the
> external module, unless someone manages to backport it to older
> kernels. 
Yes, that maybe a big problem for external module. But for ia64, we
don't want to support kernels whose version is less than 2.6.26.
However, when kernel's version grows to 2.6.27 or bigger,  we have to
provide the backward compatiblity for 2.6.26.  Agree? 
Moreover,  the users are using Linux-2.6.26, and don't want to upgrade
their kernels, but they want to use latest kvm bits to run guests.  How
to meet such the requirement in a easy way? So, I think external module
should be a better way to adopt.  

>> PS:  To make it reviewable, I splited it into small patches. The
>> first five patches intends to move x86 specific files to x86
>> directory, the sixth one for enabling Kbuild in new laylout. The
>> last one makes kvm/ia64 build components in userspace.
>> 
> 
> Please generate patches with the '-M' option (or set the
> 'diff.renames' config option) so file movement patches show up as
> such. 
Good idea! Thanks
Xiantao

Re: [PATCH 0/7][RFC] Enable kvm/ia-64 to build kvm components in userspace.

[Avi Kivity]

Zhang, Xiantao wrote:
> Avi Kivity wrote:
>   
>> Zhang, Xiantao wrote:
>>     
>>> Hi, Avi
>>>      This patchset intends to enable kvm/ia-64 to build kvm
>>> components in userspace.  You know,  current userspace code only
>>> supports x86 to build kvm components, but kvm/ia64 have to build kvm
>>> modules and qemu separately.  In this way, it is not conveninent for
>>> user-ends, and kvm's release package can't  include kvm/ia64 bits.  
>>> To make kvm userspace more friendly and common, I re-organize the
>>> kernel directory of kvm-userspace.git, and create two sub-directory
>>> (x86 and ia64)to hold arch-specific source files. With its support,
>>> ia64's end-users can build kvm/ia64 components in the same way with
>>> ia32 side, and future kvm's release packages are also capable to
>>> include ia64 bits.  Appreicate any review comments! 
>>>
>>>
>>>       
>> While I have no objection in principle, I don't understand the
>> motivation.  kvm ia64 cannot be retrofitted to older kernels (since
>> some symbols are not exported).  Why is it not sufficient to use the
>> kernel module from the kernel tree?
>>     
>
> The motivation is that developers and testers have to upgrade their
> kernels if kernel's minor version changed, otherwise the module formats
> would be incompatible.

I do this all the time; this isn't a problem for developers.

>   Especially it is not convenient for some auto
> testing systems, because the upgrading kernel process would be more
> complex.  

I agree that for automatic testing it's more of a burden; but it needs 
to be done, especially as some kvm features are only enabled on newer 
kernels.

The external module is convenient, but it's not a substitute for the 
real thing.

> In addition,  we can't alwasys require the end-users to use
> the lastest kvm.git bits as host kernels, especially for servers which
> may disallow to do a restart after enabling  kvm on it. 
>   

If the server is used primarily for virtualization, you will need to 
stop all guests anyway.

kvm.git is certainly not suitable for end-users; they should use a 
supported Linux distribution.  The distro can choose whether to include 
the upstream kvm, or it can backport kvm.git into its kernel if it wants 
newer features.

>> Eventually, the x86 external module support will be dropped as well.
>> Most noncommercial distributions already have good kvm support; the
>> only questions is what to do with RHEL/SLES/CentOs users -- wait
>> until the next major release, or wait until ovirt starts shipping?
>>     
>
>
>   
>> Note that mmu notifiers further reduce the attractiveness of the
>> external module, unless someone manages to backport it to older
>> kernels. 
>>     
> Yes, that maybe a big problem for external module. But for ia64, we
> don't want to support kernels whose version is less than 2.6.26.
> However, when kernel's version grows to 2.6.27 or bigger,  we have to
> provide the backward compatiblity for 2.6.26.  Agree? 
>   

2.6.26 has not been released!  Is this a real problem or a theoretical 
problem?

> Moreover,  the users are using Linux-2.6.26, and don't want to upgrade
> their kernels, but they want to use latest kvm bits to run guests.  How
> to meet such the requirement in a easy way? So, I think external module
> should be a better way to adopt.  
>   

Well the same problem exists for network drivers.  The kernel.org 
solution is to use the newer kernel, the distro solution is to backport 
the changes to the older kernel, if there is user demand.

As I mentioned, I'm not opposed in principle, but I want to be sure 
we're solving a real problem, since external module maintenance is not 
trivial.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

RE: [PATCH 0/7][RFC] Enable kvm/ia-64 to build kvm components in userspace.

[Zhang, Xiantao]

Avi Kivity wrote:
> Zhang, Xiantao wrote:
>> Avi Kivity wrote:
>> 
>>> Zhang, Xiantao wrote:
>>> 
>>>> Hi, Avi
>>>>      This patchset intends to enable kvm/ia-64 to build kvm
>>>> components in userspace.  You know,  current userspace code only
>>>> supports x86 to build kvm components, but kvm/ia64 have to build
>>>> kvm modules and qemu separately.  In this way, it is not
>>>> conveninent for user-ends, and kvm's release package can't 
>>>> include kvm/ia64 bits. To make kvm userspace more friendly and
>>>> common, I re-organize the kernel directory of kvm-userspace.git,
>>>> and create two sub-directory (x86 and ia64)to hold arch-specific
>>>> source files. With its support, ia64's end-users can build
>>>> kvm/ia64 components in the same way with ia32 side, and future
>>>> kvm's release packages are also capable to include ia64 bits. 
>>>> Appreicate any review comments! 
>>>> 
>>>> 
>>>> 
>>> While I have no objection in principle, I don't understand the
>>> motivation.  kvm ia64 cannot be retrofitted to older kernels (since
>>> some symbols are not exported).  Why is it not sufficient to use the
>>> kernel module from the kernel tree?
>>> 
>> 
>> The motivation is that developers and testers have to upgrade their
>> kernels if kernel's minor version changed, otherwise the module
>> formats would be incompatible.
> 
> I do this all the time; this isn't a problem for developers.

Actually, so do I.  But for testers or new comers, it maybe a big
problem. 

>>   Especially it is not convenient for some auto
>> testing systems, because the upgrading kernel process would be more
>> complex.
> 
> I agree that for automatic testing it's more of a burden; but it needs
> to be done, especially as some kvm features are only enabled on newer
> kernels.
> 
> The external module is convenient, but it's not a substitute for the
> real thing.

So, I have a question here, When will you drop external module support?
You know, it blocks our auto-testing system now, we have to re-evaulate
the effort without external module support. 
If it won't be dropped in a few weeks, we are eager to get its support
for kvm-ia64.

>> In addition,  we can't alwasys require the end-users to use
>> the lastest kvm.git bits as host kernels, especially for servers
>> which may disallow to do a restart after enabling  kvm on it.
>> 
> 
> If the server is used primarily for virtualization, you will need to
> stop all guests anyway.

Agree. But for new users, it maybe a potential restart required for
upgrading kernel. 

> kvm.git is certainly not suitable for end-users; they should use a
> supported Linux distribution.  The distro can choose whether to
> include the upstream kvm, or it can backport kvm.git into its kernel
> if it wants newer features.

Backport maybe need more effort once without external module support. 

>>> Eventually, the x86 external module support will be dropped as well.
>>> Most noncommercial distributions already have good kvm support; the
>>> only questions is what to do with RHEL/SLES/CentOs users -- wait
>>> until the next major release, or wait until ovirt starts shipping?
>>> 
>> 
>> 
>> 
>>> Note that mmu notifiers further reduce the attractiveness of the
>>> external module, unless someone manages to backport it to older
>>> kernels. 
>>> 
>> Yes, that maybe a big problem for external module. But for ia64, we
>> don't want to support kernels whose version is less than 2.6.26.
>> However, when kernel's version grows to 2.6.27 or bigger,  we have to
>> provide the backward compatiblity for 2.6.26.  Agree?
>> 
> 
> 2.6.26 has not been released!  Is this a real problem or a theoretical
> problem?

>From the long run, the problem should exist.  IMO, we had better provide
external module support for some recent kernel versions, instead of
canceling it.  
 
>> Moreover,  the users are using Linux-2.6.26, and don't want to
>> upgrade their kernels, but they want to use latest kvm bits to run
>> guests.  How to meet such the requirement in a easy way? So, I think
>> external module should be a better way to adopt.
>> 
> 
> Well the same problem exists for network drivers.  The kernel.org
> solution is to use the newer kernel, the distro solution is to
> backport the changes to the older kernel, if there is user demand.
> 
> As I mentioned, I'm not opposed in principle, but I want to be sure
> we're solving a real problem, since external module maintenance is not
> trivial.

Re: [PATCH 0/7][RFC] Enable kvm/ia-64 to build kvm components in userspace.

[Avi Kivity]

Zhang, Xiantao wrote:
>>
>> I agree that for automatic testing it's more of a burden; but it needs
>> to be done, especially as some kvm features are only enabled on newer
>> kernels.
>>
>> The external module is convenient, but it's not a substitute for the
>> real thing.
>>     
>
> So, I have a question here, When will you drop external module support?
>   

I don't really know.

> You know, it blocks our auto-testing system now, we have to re-evaulate
> the effort without external module support. 
>   

I think it's very worthwhile to update the autotester to be able to 
build kernels. kvm will soon depend on core functionality (mmu 
notifiers) and since currently kvm is the only user (well, gru will be 
added soon, but ...) we need to test it ourselves.

> If it won't be dropped in a few weeks, we are eager to get its support
> for kvm-ia64.
>
>   

Okay, please send the patches, but with diff -M so they're readable.

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

RE: [PATCH 0/7][RFC] Enable kvm/ia-64 to build kvm components in userspace.

[Zhang, Xiantao]

Avi Kivity wrote:
> Zhang, Xiantao wrote:
>>> 
>>> I agree that for automatic testing it's more of a burden; but it
>>> needs to be done, especially as some kvm features are only enabled
>>> on newer kernels. 
>>> 
>>> The external module is convenient, but it's not a substitute for
>>> the real thing. 
>>> 
>> 
>> So, I have a question here, When will you drop external module
>> support? 
>> 
> 
> I don't really know.
> 
>> You know, it blocks our auto-testing system now, we have to
>> re-evaulate the effort without external module support.
>> 
> 
> I think it's very worthwhile to update the autotester to be able to
> build kernels. kvm will soon depend on core functionality (mmu
> notifiers) and since currently kvm is the only user (well, gru will be
> added soon, but ...) we need to test it ourselves.
> 
>> If it won't be dropped in a few weeks, we are eager to get its
>> support for kvm-ia64. 
>> 
>> 
> 
> Okay, please send the patches, but with diff -M so they're readable.

OK, I will regenerate the patches.  Thanks!
Xiantao