On 6/16/26 17:58, Gregory Price wrote: > On Tue, Jun 16, 2026 at 05:52:29PM +0200, David Hildenbrand (Arm) wrote: >> On 6/16/26 16:44, Gregory Price wrote: >>> That makes sense, although don't you just push the blocking operation >>> into yet another thread on the host? >> >> I think timers are run from the QEMU main thread, so no separate thread just >> for >> the timer. >> >> And IIRC, there will be no blocking. At least if I understand your concern >> correctly. >> >> balloon_stats_poll_cb() will do a virtqueue_push()+virtio_notify(), which >> will >> notify the device. The main thread will continue afterwards doing what a main >> thread usually does. >> >> A VCPU will process the request in the VM and send it back + notify the >> device. >> > > Entirely possible I just bungled the interaction then and/or CH's > interfaces introduce a blocking op that shouldn't. > > Thanks for the feedback, we can probably drop this patch. Unless > there's any particular pushback for 1/2, should i leave as-is or > resubmit separately w/o RFC?
Probably best to send #1 as non-RFC after the merge window. -- Cheers, David
