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. Kevin
signature.asc
Description: PGP signature
