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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
