Dong, Eddie wrote:
> [EMAIL PROTECTED] wrote:
>   
>> Avi Kivity wrote:
>>     
>>> Dong, Eddie wrote:
>>>       
>>>> Avi:
>>>>    To make lapic code into mainline earlier, I am thinking what
>>>> should the user space code look like.  If we wait till lapic branch
>>>> has all same functionality as mainline have today i.e. live
>>>> migration, all guests etc, we may have very long way to go given
>>>> that only Greg (temply off), me have contribution to the code
>>>> besides you. So what I am thinking is to reduce the bar to "no
>>>> regression", which means a user space command to choice kernel
>>>> pic/apic. When choosing user pic/apic, we make sure everything works
>>>> including livemigration and all known good guests; if choosing
>>>> kernel pic/apic, we have better performance but some feature lagging
>>>>    such as live migration. Does this make sense? If yes, How about
>>>> command option "-irqchip k" and "-irqchip u"? the default value is
>>>> user. 
>>>>
>>>>         
>>> That doesn't work; one day we'll make kernel apic the default, and
>>> then that new userspace won't work with kernels that have in-kernel
>>> pic but not lapic. 
>>>
>>>       
>> After we get everything settled down, we can switch the default
>> setting to "kernel". BTW, I am talking about generic lapic solution,
>> not current one in lapic2 branch. Definitely we need to pull in
>> kernel apic+ioapic first before the push back. But I think now we
>> should make a high level decision on how we will handle this merge
>> and how will user space look like. 
>>
>>     
> Avi:
>       Can u show clear light here? We need to go forward quickly:-)
> Eddie
>   

If we release a kernel with pic but not lapic, and userspace that 
defaults to user-pic+lapic, then that kernel will not work with a newer 
userspace that defaults to in-kernel pic+lapic.

We need to switch in one go.  I don't mind checking in patches to the 
lapic2 branch, and continually rebasing it against master, but a release 
will only happen when everything works.

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


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Reply via email to