Hi, > There isn't a notion of "connected" for the front-ends in the char > layer. The closest thing is whether add_handlers() have been called or > not.
It isn't new. There are qemu_chr_fe_open + qemu_chr_fe_close doing exactly that signaling (whenever someone has opened the virtio-serial port, i.e. whenever the guest agent is active or not). Problem is the chardev forgets this state over migration. So we need a way to restore the state. virtio-serial knows it of course as this is guest state it has to keep track of it. We just need a way the chardev can figure what the current state is after migration. The options I see: (1) Have chardev store the state itself in a new migration section. This is what I've NAK'ed. First, because live-migration host state is a can of worms I don't want open. Second because it actually isn't host state. (2) virtio-serial could just call qemu_chr_fe_open in post_migration hook. Could have unwanted side effects as the chardev can't figure whenever this is a post-load call or a guest-open call. (3) Add a new qemu_chr_fe_* call for virtio-serial to notify the chardev. This was the next proposal from Alon (4) Do it the other way around: Allow the chardev query what the current state is. This patch series. (5) Cut off the chardev layer altogether and implement spicevmc as virtio-serial port. Your proposal if I understand it correctly. Makes sense, but breaks backward compatibility, so even when doing this we must fix the chardev spicevmc bug somehow. Hope this clarifies, Gerd