Comment 7 for bug 1851062

Interesting, so the main qemu in the host consumes ~17% user and ~18% system while this is going on. And this goes on for at least the 15 seconds we traced things (and from your report I assume it keeps going on).

We also see context switches, but no faults - this really just seems to "do something".
Very odd and very unexpected @pedro.

Nothing is spend in the guest, matching what you'd expect after pausing.
I'd understand some buffer flushes or cleanups but those should stop after a while.
But if you say this "keep going" I agree that it feels odd.

With these logs I'd at least call it confirmed for now.
But it seems we need to go step by step analazing what is going on.

The next obvious step once you again see such a case would be to check "what" the qemu is doing on the host.

I'm not sure how experienced you are with profiling workload.
If you are please just dive deep and report what you find.
If you are not I can give suggestions every step but we will have to ping/pong this back and forth until we have something.

When in this paused-but-busy state you could next time run:
$ sudo strace -rT -ff -f -o paused-but-busy -p $(pidof qemu-system-x86_64)
Please at the same time also run the other one you already used so that we can match thread IDs:
$ pidstat -p $(pidof qemu-system-x86_64) -T ALL -rtuw 5 5

Also with the guest paused I'd expect the following not to move:
for i in $(seq 1 5); do virsh domstats "<yourguestname>"; sleep 5; done