On Tue, Jun 16, 2026 at 04:32:46PM +0200, David Hildenbrand (Arm) wrote: > On 6/16/26 15:57, Gregory Price wrote: > > > > Definitely an RFC here because I'm not sure if I was missing something > > that might help me solve the problem. > > Well, in QEMU we just run a timer internally that does the polling. > > Then, upper layers in the stack can ask QEMU for the latest stats. > > There, you just get the stats along with a "last-update" timestamp. >
That makes sense, although don't you just push the blocking operation into yet another thread on the host? Assuming it's not cancel-able, there's a blocked thread there you have to reap. Vs the guest being unresponsive and not sending updates, you just reap the whole guest or take some other corrective action. I suppose to the orchestrator reaping QEMU and reaping the guest looks the same. The difference is just where the thread lives, hmmmm I'll make a note to inspect QEMU's solution to see if that's handled or if it would be subject to the same issue. Thanks! ~Gregory
