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

[Marcelo Tosatti <mtosatti@redhat.com>]

On Tue, Feb 01, 2011 at 06:34:50PM +0100, Jan Kiszka wrote:
> 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).

qemu-kvm has this modification for performance reasons.
SIGUSR2 can't be blocked otherwise. See example test case at
https://patchwork.kernel.org/patch/20817/.

Problem is that you can't block the AIO signal and process it via
signalfd because of synchronous IO emulation:

- submit io
- qemu_aio_wait

Since the aio signal is processed in main_loop_wait by the iothread, the
above deadlocks. To be more clear:

SIGUSR2 unblocked:
signal -> aio_signal_handler -> write(posix_fd)

SIGUSR2 blocked:
signal -> signalfd -> aio_signal_handler -> write(posix_fd)

It would be good to maintain this behaviour upstream, before switching
(can be selective on CONFIG_IOTHREAD), IMO.