On Mon, Feb 14, 2022 at 12:38:22PM +0100, Kevin Wolf wrote: > Am 14.02.2022 um 11:09 hat Stefan Hajnoczi geschrieben: > > On Fri, Feb 11, 2022 at 12:32:57PM +0100, Kevin Wolf wrote: > > > Am 03.02.2022 um 15:19 hat Stefan Hajnoczi geschrieben: > > > > On Thu, Feb 03, 2022 at 10:56:49AM +0000, Daniel P. Berrangé wrote: > > > > > On Thu, Feb 03, 2022 at 10:53:07AM +0000, Stefan Hajnoczi wrote: > > > > > > On Wed, Feb 02, 2022 at 06:52:34PM +0100, Nicolas Saenz Julienne > > > > > > wrote: > > > > 1. A global default value that all new AioContext take. The QEMU main > > > > loop's qemu_aio_context will use this and all IOThread AioContext > > > > will use it (unless they have been overridden). > > > > > > > > I would define it on --machine because that's the "global" object for > > > > a guest, but that's not very satisfying. > > > > > > Semantically, -machine is about the virtual hardware where as iothreads > > > are about the backend, so I agree it's not a good fit. > > > > > > For the main thread, you may want to configure all the same options that > > > you can configure for an iothread. So to me that sounds like we would > > > want to allow using an iothread object for the main thread, too. > > > > > > That would still require us to tell QEMU which iothread object should be > > > used for the main thread, though. > > > > Making the main loop thread an IOThread is an interesting direction but > > not an easy change to make. > > > > The main loop thread has a custom event loop that is not interchangeable > > with the IOThread event loop: > > - The main loop has a poll notifier interface for libslirp fd monitoring > > integration. > > - The main loop is a GLib event loop but manually polls to get > > nanosecond resolution timers. > > - The main loop has icount integration. > > - The main loop has the special iohandler AioContext > > > > The IOThread event loop runs an optimized AioContext event loop instead. > > It falls back to regular g_main_loop_run() if there is a GSource user. > > > > It would definitely be nice to unify the main loop with IOThread and > > then use --object iothread,... to configure main loop parameters. > > > > I'm not sure if requiring that of Nicolas is fair though. The event > > loops in QEMU are complex and changes are likely to introduce subtle > > bugs or performance regressions. > > I'm not suggesting actually running the iothread event loop instead, > merely using the properties of an object to configure the main thread as > the external user interface. > Whether this uses the same main loop code as today or is moved to the > regular iothread event loop is an implementation detail that can be > changed later. > > Or we could maybe use a different object type like 'mainthread' and > share the properties using QOM inheritance.
That seems cleaner than trying faking an IOThread to me since I don't see a concrete plan to unify the two event loops. The main loop code is in util/main-loop.c. Maybe call it --object main-loop? Attempting to instantiate more than one main-loop object should fail. Stefan
signature.asc
Description: PGP signature
