On Tue, Oct 25, 2016 at 03:57:34PM -0400, John Ferlan wrote: > > > On 10/25/2016 08:48 AM, Pavel Hrdina wrote: > > On Mon, Oct 24, 2016 at 06:46:18PM -0400, John Ferlan wrote: > >> Rather than remove the frontend first and then the backend, let's swap the > >> order. The order of addition is add the chardev backend if EGD being used, > >> then add the RNG object. So there's a dependency there. When we remove, > >> unplug the backend first, then remove the object would seem to be a more > >> logical step. This would then follow similar processing for disk removal > >> where dependent objects (secret and encryption) of the drive are removed > >> before the drive is removed. > > > > Nice catch, qemuDomainRemoveChrDevice needs the same fix. > > > > Going through my pencil/paper exercise, I think I was wrong... Too many > objects and similar names. > > During the attach processing we have (up to this point at least) > > 1. Add TLS Object (if necessary) > 2. Attach chardev for EGD Backend (if necessary) > -> NB: Could depend on 1 via 'tlsProps' > 3. Add frontend object > -> NB: Could depend on 2 via 'props' > 4. Add device > > So the corollary then becomes: > > 1. Detach Device (in DetachRNGDevice) > 2. Delete frontend object (in RemoveRNGDevice) > 3. Detach chardev for EGD Backend (if necessary) > 4. Delete TLS object > > When the secobj is added later it's added before TLS and removed after TLS. > > Since the existing code has the above order, this patch I think is > dropped... That does effect the next one, but only insomuch as placement > of the delete TLS object per the above order.
OK I've checked it again and properly this time and I've check qemu command line too: -chardev socket,id=charrng0,host=localhost,port=4466,server,nowait -object rng-egd,id=objrng0,chardev=charrng0 -device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.2,addr=0x2 So the dependency is clear and yes this patch was making it wrong. I've for some reason thought that the objAlias means a different object, sigh, shame on me :) Pavel
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
