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