On Fri, Mar 18, 2022 at 09:48:37AM +0100, Paolo Bonzini wrote: > Hi all, > > based on the previous discussions here is a comparison of the various > possibilities for implementing coroutine backends in QEMU and the > respective advantages and disadvantages. > > I'm adding a third possibility for stackless coroutines, which is to > use the LLVM/clang builtins. I believe that would still require a > source-to-source translator, but it would offload to the compiler the > complicated bits such as liveness analysis. > > 1) Stackful coroutines: > Advantages: > - no changes to current code > > Disadvantages: > - portability issues regarding shadow stacks (SafeStack, CET) > - portability/nonconformance issues regarding TLS > > Another possible advantage is that it allows using the same function for > both coroutine and non-coroutine context. I'm listing this separately > because I'm not sure that's desirable, as it prevents compile-time > checking of calls to coroutine_fn. Compile-time checking would be > possible using clang -fthread-safety if we forgo the ability to use the > same function in both scenarios. > > > 2) "Duff's device" stackless coroutines > Advantages: > - no portability issues regarding both shadow stacks and TLS > - compiles to good old C code > - compile-time checking of "coroutine-only" but not awaitable functions > - debuggability: stack frames should be easy to inspect > > Disadvantages: > - complex source-to-source translator
I guess I'm still a bit fuzzy on the actual implications of this point. Is this a one time hit to write it, or is it something that is going to need periodic (even frequent) updates to cope with new places in which we use coroutines ? Presumably most maintainers won't have to care about / look at the details of it ? > - more complex build process > > > 3) C++20 stackless coroutines > Advantages: > - no portability issues regarding both shadow stacks and TLS > - no code to write outside QEMU > - simpler build process > > Disadvantages: > - requires a new compiler > - it's C++ > - no compile-time checking of "coroutine-only" but not awaitable functions > > > 4) LLVM stackless coroutines > Advantages: > - no portability issues regarding both shadow stacks and TLS > - no code to write outside QEMU > > Disadvantages: > - relatively simple source-to-source translator > - more complex build process > - requires a new compiler and doesn't support GCC > > > Note that (2) would still have a build dependency on libclang. > However the code generation could still be done with GCC and with > any compiler version. We looked at using libclang for some code generation in libvirt, via its python API binding. While we didn't go forward with it (yet), it looked promising as a library to use. IIRC, it was viable from clang vintage available in RHEL-8 onwards, as versions before that point were not compatible with the current python binding. I think it would cover all the mainstream platforms that QEMU officially targets and tests in CI right now. I think libclang might also be an interesting framework on which to experiment with code analysis checks, to augment (or even replace) some of what is done by checkpatch.pl With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
