Il 22/02/2013 11:43, Stefan Hajnoczi ha scritto: >> > >> > 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.
Ah :) > 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). I think scoped worker threads are simpler to implement and have little or no lock contention (I have patches for lockless thread-pool, but I'm not 100% sure they're correct---and they're a bit ugly). Also, with many virtio-blk threads you could hit the 64-thread limit that thread-pool has, so it may require some tuning. More importantly, scoped worker thread do not require an external iothread to exist at all. We can switch from one solution to the other easily (benchmarking takes more time than coding, in all likelihood), so it's not urgent to choose one over the other now. >> 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. Indeed, we don't share BDSs but commit operations could cause the same file to be backed by two BDSs, one read-only and one read-write. >> 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. Not a big deal anyway (like the irqfd). Paolo
