Re: [PATCH v11 2/5] qemu: Swap order of RNG hot unplug removal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Attachment: signature.asc
Description: Digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]