Am 14.02.2022 um 14:10 hat Stefan Hajnoczi geschrieben: > 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.
Sounds good. And if you don't create one explicitly, we'll just internally create a default main-loop object. Kevin
signature.asc
Description: PGP signature
