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

[Hans de Goede]

Hi,

On 03/21/2013 07:18 PM, Anthony Liguori wrote:
> Alon Levy <address@hidden> writes:
>
> > Note that the handler is called chr_is_guest_connected and not
> > chr_is_fe_connected, consistent with other members of CharDriverState.
>
> Sorry, I don't get it.
>
> There isn't a notion of "connected" for the front-ends in the char
> layer.

And that is simply completely and utterly wrong. We've tried to explain
this to you a number of times already. Yet you claim we've not explained
it. Or we've not explained it properly. I must say however that I'm
getting the feeling the problem is not us not explaining, but that you
are not listening.

Still let me try to explain it 1 more time, in 2 different ways:

1) At an abstract level a chardev fe + be is a pipe between somewhere
and where-ever. Both ends of the pipe can be opened or closed, not just
one.

Frontends end inside the guest usually in the form of some piece of
virtual hardware inside the guest. Just because the virtual hardware
is there does not mean the guest has a driver, if the guest has
a driver that creates a device-node for it, that does not mean there
is a userspace process inside the guest which actually has the
device-node open. So you see the front-end device-node inside the guest
can be opened and closed. Most frontends cannot signal this to the
backend but virtio-console can, and we want to know about it since
we want to know if the user-space agent is there.

2) At the code level it clearly is there too, backend open-close
is signalled to the frontend by means of the backend calling
qemu_chr_be_event with an event of CHR_EVENT_OPENED and
CHR_EVENT_CLOSED. Frontend open-close is signalled by the
frontend calling qemu_chr_fe_open and qemu_chr_fe_close.

Now the problem we have is that after migration the CHR_EVENT_OPENED
gets replayed on the destination side but the qemu_chr_fe_open call
does not.

The logical place to replay the qemu_chr_fe_open would be in the
frontend's migration handling code, as suggested here:
http://lists.gnu.org/archive/html/qemu-devel/2012-11/msg02721.html

But Amit did not like this approach, suggesting that instead we
took care of this inside spice-qemu-char.c. Which is what we're
trying to do now, but this requires spice-qemu-char.c being
able to query the open state of the frontend, which is already
being migrate by the virtio-console code in the form of the
guest_connected variable, we just need to be able to get to that
variable from the backend.

Regards,

Hans