[libvirt] [PATCH v11 2/5] qemu: Swap order of RNG hot unplug removal
Pavel Hrdina
phrdina at redhat.com
Tue Oct 25 21:15:44 UTC 2016
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20161025/ad02e410/attachment-0001.sig>
More information about the libvir-list
mailing list