[Qemu-devel] Re: KVM call minutes for Feb 1

[Jan Kiszka]

On 2011-02-01 18:20, Anthony Liguori wrote:
> On 02/01/2011 11:03 AM, Jan Kiszka wrote:
>> On 2011-02-01 17:53, Anthony Liguori wrote:
>>    
>>> On 02/01/2011 10:36 AM, Jan Kiszka wrote:
>>>      
>>>> On 2011-02-01 16:54, Chris Wright wrote:
>>>>
>>>>        
>>>>> KVM upstream merge: status, plans, coordination
>>>>> - Jan has a git tree, consolidating
>>>>> - qemu-kvm io threading is still an issue
>>>>> - Anthony wants to just merge
>>>>>     - concerns with non-x86 arch and merge
>>>>>     - concerns with big-bang patch merge and following stability
>>>>> - post 0.14 conversion to glib mainloop, non-upstreamed qemu-kvm will be
>>>>>     a problem if it's not there by then
>>>>> - testing and nuances are still an issue (e.g. stefan berger's mmio read 
>>>>> issue)
>>>>> - qemu-kvm still evolving, needs to get sync'd or it will keep diverging
>>>>> - 2 implementations of main init, cpu init, Jan has merged them into one
>>>>>     - qemu-kvm-x86.c file that's only a few hundred lines
>>>>> - review as one patch to see the fundamental difference
>>>>>
>>>>>          
>>>> More precisely, my current work flow is to pick some function(s), e.g.
>>>> kvm_cpu_exec/kvm_run, and start wondering "What needs to be done to
>>>> upstream so that qemu-kvm could use that implementation?". If they
>>>> differ, the reasons need to be understood and patched away, either by
>>>> fixing/enhancing upstream or simplifying qemu-kvm. Once the upstream
>>>> changes are merged back, a qemu-kvm patch is posted to switch to that
>>>> version.
>>>>
>>>> Any help will be welcome, either via review of my subtle regressions or
>>>> on resolving concrete differences.
>>>>
>>>> E.g. posix-aio-compat.c: Why does qemu-kvm differ here? If it's because
>>>> of its own iothread code, can we wrap that away or do we need to
>>>> consolidate the threading code first? Or do we need to fix something in
>>>> upstream?
>>>>
>>>>        
>>> I bet it's the eventfd thing.  It's arbitrary.  If you've got a small
>>> diff post your series, I'd be happy to take a look at it and see what I
>>> can explain.
>>>
>>>      
>> Looks like it's around signalfd and its emulation:
>>    
> 
> I really meant the compatfd thing.
> 
> signalfd can't really be emulated properly so in upstream we switched to 
> a pipe() which Avi didn't like.
> 
> But with glib, this all goes away anyway so we should just drop the 
> qemu-kvm changes and use the upstream version.  Once we enable I/O 
> thread in qemu.git, we no longer need to use signals for I/O completion 
> which I think everyone would agree is a better solution.

Don't understand: If we do not need SIGIO for AIO emulation in threaded
mode, why wasn't that stubbed out already? If that helps reducing
worries about the signalfd emulation (which is likely a non-issue anyway
as anyone with serious workload should run a kernel with such support).

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux