Hi Bernd, Am 04.08.2025 um 13:33 hat Bernd Schubert geschrieben: > Hi Brian, > > sorry for my late reply, just back from vacation and fighting through > my mails. > > On 8/4/25 01:33, Brian Song wrote: > > > > > > On 2025-08-01 12:09 p.m., Brian Song wrote: > >> Hi Bernd, > >> > >> We are currently working on implementing termination support for fuse- > >> over-io_uring in QEMU, and right now we are focusing on how to clean up > >> in-flight SQEs properly. Our main question is about how well the kernel > >> supports robust cancellation for these fuse-over-io_uring SQEs. Does it > >> actually implement cancellation beyond destroying the io_uring queue? > >> > >> In QEMU FUSE export, we need a way to quickly and cleanly detach from > >> the event loop and cancel any pending SQEs when an export is no longer > >> in use. Ideally, we want to avoid the more drastic measure of having to > >> close the entire /dev/fuse fd just to gracefully terminate outstanding > >> operations. > >> [...]
> I have to admit that I'm confused why you can't use umount, isn't that > the most graceful way to shutdown a connection? > > If you need another custom way for some reasons, we probably need > to add it. Brian focussed on shutdown in his message because that is the scenario he's seeing right now, but you're right that shutdown probably isn't that bad and once we unmount the exported image, we can properly shut down things on the QEMU side, too. The more challenging part is that sometimes QEMU needs to quiesce an export so that no new requests can be processed for a short time. Maybe we're switching processing to a different iothread or something like this. In this scenario, we don't actually want to unmount the image, but just cancel any outstanding COMMIT_AND_FETCH request, and soon after submit a new one to continue processing requests. If it's impossible to cancel the request in the kernel and queue new request for a little bit (I suppose it would look a bit like userspace being completely busy processing hypothetical NOP requests), we would have to introduce some indirections in userspace to handle the case that CQEs may be posted at times when we don't want to process them, or even in the ring of the wrong thread (each iothread in QEMU has it's own io_uring instance). Come to think of it, the next thing the user may want to do might even be deleting the old thread, which would have to fail while it's still busy. So I think we do need a way to get rid of requests that it started and can't just wait until they are used up. Kevin
