[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