On 4/4/22 11:51, Emanuele Giuseppe Esposito wrote: >> >> I agree that it doesn't. This new lock is only protecting ->parents and >> ->children. > Side note: it will also be used to protect other fields, like > .aio_context I think. I haven't checked if there is something else we > might want to protect that is currently protected by AioContext lock. > > At least, I think we are going to use the same lock, right?
I have no idea honestly. It can make sense for anything that is changed very rarely and read during requests. .aio_context has the .detach/.attach callbacks and I wonder if there should be any reason to access it outside the callbacks. A lot of uses of .aio_context (for example for aio_bh_new or aio_bh_schedule_oneshot/replay_bh_schedule_oneshot_event) can, and perhaps should, be changed to just qemu_get_current_aio_context(). For multiqueue we probably want the same BlockDriverState to use the AioContext corresponding to a virtio queue, rather than always the same one. Paolo
