Re: [Qemu-devel] [PATCH 1/2] char: add qemu_chr_be_is_fe_connected

[Gerd Hoffmann <kraxel@redhat.com>]

  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