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

[Avi Kivity <avi@qumranet.com>]

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.