Re: strace showing QEMU process doing >99% ppoll

[Fiona Ebner <f.ebner@proxmox.com>]

Am 10.07.23 um 14:34 schrieb Fiona Ebner:
> Hi,
> since a while we have about a dozen people reporting [0] VMs rarely
> getting stuck with the QEMU process looping and just doing ppoll() and
> not much else (example strace [1] output and stacktrace [2]).
> 
> Just wanted to ask if anybody here has seen something similar or ideas
> what could go wrong? There seem to be at least two different issues:
> 

If anybody else stumbles upon this:

> 1. QEMU process looping calling only ppoll, guest completely
> non-responsive. I think QMP still working normally, but I had no debug
> access to these unfortunately.
> 

We did have debug access in the mean time and couldn't tell much, just
that all the vCPUs where spinning, QEMU itself seemed to run like usual.
In the end, it turned out to be a KVM bug, fixed in v6.1 by [0] and in
v6.3+ unknowingly by a refactoring.

> 2. Also QEMU looping around ppool, but the PLT (process linkage table)
> is corrupted [3]. I did have debug access to such a machine and saw the
> jump to the wrong address first hand. Call into _ppoll() results landing
> in the middle of internal_fallocate64 instead and the vCPU threads end
> up in preadv64v2() (note that the flags=44672 very much looks like
> KVM_RUN being AE80 in hex). AFAIU that memory should be read-only so
> maybe a kernel bug (the machine I debugged was running on host kernel 5.15)?
> 

No Idea about this one, but we never saw other reports again, so I
suspect some stable backport fixed it too.

Best Regards,
Fiona

[0]:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.1.51&id=82d811ff566594de3676f35808e8a9e19c5c864c