On Thu, Feb 21, 2013 at 06:05:44PM +0100, Paolo Bonzini wrote: > Il 21/02/2013 17:33, Stefan Hajnoczi ha scritto: > > This especially means things like adding live > > migration support or solving other limitations. The limitations are > > there to motivate core QEMU refactoring, so that core QEMU code can be > > used directly instead of reimplementing it. > > > > Here's my TODO list: > > * Thread pool <-> AioContext > > > > The thread pool uses an EventNotifier to invoke callbacks. In a > > multiple event loop world we need to invoke callbacks in the event > > loop that they are associated with. > > > > Worker threads are also started using a BH so that the thread > > inherits the iothread CPU affinity and other characteristics. I > > think this can stay. > > It can and should stay. :) BHs are tied to an AioContext. Running > thread-creation BHs from the AioContext's main thread ensures that the > worker threads inherit the right attributes for e.g. real-time.
When I say "this can stay" I mean that worker threads will be spawned from the QEMU iothread, not from the caller's thread. Why? Because if we decide to change this then we can no longer have a global set of worker threads and a single work queue. It would make worker threads scoped to just one AioContext. Do we really want to go there? It kind of defeats the purpose of a thread-pool to have one thread-pool per AioContext (i.e. per virtio-blk device). > > * BlockDriverState <-> AioContext > > > > It probably makes sense to bind a BlockDriverState to an AioContext > > in which its file descriptors and aio activity happens. > > ... and have the full chain of BlockDriverStates (bs->file, > bs->backing_file and any others as in the vmdk driver) bound to a single > AioContext. We will use two BlockDriverStates if the same backing file > happens to be shared by two disks (BTW, anybody ever checked what kind > of havoc happens if you commit to such a BDS? :)). AFAIK we don't share backing file BlockDriverStates today. > > * Thread-friendly interrupt API > > What is this? Raising interrupts, I think we're already okay using irqfd today but maybe it's nicer to make the regular QEMU irq APIs support this instead of manually using irqfd. > What's still missing here is TCG support. Perhaps you can emulate > ioeventfd at the hw/virtio.c level and always going through a host > notifier. In retrospect, perhaps it was a mistake to make ioeventfd a > non-experimental option. That's true. We need to emulate ioeventfd. For virtio-pci we can cheat by simply notifying the EventNotifier from the virtqueue kick handler. But really we should implement an ioeventfd equivalent at the pio/mmio emulation level in QEMU. Stefan
