> > Again, this feels like a qemu-stable material. However, I'm not > sure under which circumstances the uuid key can be freed before > referencing.
To clarify the circumstances: in a cross-device sharing scenario like vhost-device-gpu to vhost-device-video if the GPU side UUID is not duplicated, the lookup will fail when the Video device later tries to reference that UUID. > But I wonder - for example, 10.0.x is currently a long-term stable > release. If rust-vmm changes and implements this feature, won't we > hit this issue there? But this time, with a painful debugging session > because the current context is forgotten already? :) Hmm, you're right, Better to be safe than sorry, given it's a small fix let's keep it in stable then. Thanks for catching that! Br, Dorinda. On Sun, Feb 8, 2026 at 8:18 AM Michael Tokarev <[email protected]> wrote: > On 2/6/26 18:00, Dorinda Bassey wrote: > > Hi, > > > > Again, this feels like a qemu-stable material. However, I'm not > > sure under which circumstances the uuid key can be freed before > > referencing. > > > > Please let me know if I shouldn't pick this up for qemu stable > > releases. > > > > I don't think there's a need to pick this up for stable, I found this > > issue when testing the `resource_assign_uuid` feature, which is not yet > > fully implemented in rust-vmm vhost-device-gpu backend that uses it. So > > safe to say no existing users are hitting this code path in the current > > stable. > > This makes sense. I'm dropping this one from the stable series. > > But I wonder - for example, 10.0.x is currently a long-term stable > release. If rust-vmm changes and implements this feature, won't we > hit this issue there? But this time, with a painful debugging session > because the current context is forgotten already? :) > > Thank you > >
