This "would" conflict with other TLS/TCP changes on list depending on order of commit, but it does work against the current top. The conflict would be limited to the new helper qemuDomainGetChardevTLSObjects and changing the 'if (!cfg->chardevTLS)' to the corresponding 'if dev->source.data.tcp.haveTLS != VIR_TRISTATE_BOOL_YES)' once Pavel's changes are in and of course removing the need to fetch 'cfg'. Then if my other changes related to making 'source' a pointer in the _virDomainChrDef is accepted, the 'source.' here would change to 'source->'. Essentially during the review process of adding a secret to access the TLS environment, it was determined that the backends for redirdev and rng weren't adding the TLS object on hotplug, even though the command line processing would add it. NB: Smartcard would be in the same category, but it doesn't support hotplug, so we're off the hook for that. John Ferlan (4): qemu: Introduce qemuDomainGetChardevTLSObjects for hotplug qemu: Clean up error path in qemuDomainAttachRedirdevDevice qemu: Add TLS hotplug for qemuDomainAttachRedirdevDevice qemu: Add TLS hotplug for qemuDomainAttachRNGDevice src/qemu/qemu_hotplug.c | 125 ++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 99 insertions(+), 26 deletions(-) -- 2.7.4 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list