Re: [Qemu-devel] [PATCH 1/4] char: add a post_load callback

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 03/21/2013 09:27 AM, Hans de Goede wrote:
> Hi,
>
> On 03/20/2013 07:59 PM, Anthony Liguori wrote:
>> Alon Levy <alevy@redhat.com> writes:
>>
>>>> Alon Levy <alevy@redhat.com> writes:
>>>>
>>>>> Signed-off-by: Alon Levy <alevy@redhat.com>
>>>>> ---
>>>>>   include/char/char.h | 12 ++++++++++++
>>>>>   qemu-char.c         |  7 +++++++
>>>>>   2 files changed, 19 insertions(+)
>>>>>
>>>>> diff --git a/include/char/char.h b/include/char/char.h
>>>>> index 0326b2a..0fdcaf9 100644
>>>>> --- a/include/char/char.h
>>>>> +++ b/include/char/char.h
>>>>> @@ -70,6 +70,7 @@ struct CharDriverState {
>>>>>       void (*chr_set_echo)(struct CharDriverState *chr, bool echo);
>>>>>       void (*chr_guest_open)(struct CharDriverState *chr);
>>>>>       void (*chr_guest_close)(struct CharDriverState *chr);
>>>>> +    void (*chr_post_load)(struct CharDriverState *chr, int
>>>>> connected);
>>>>
>>>> The character device layer should *not* be messing around with
>>>> notifying
>>>> migration state.
>>>>
>>>> I thought we previously discussed this?  Just implement a migration
>>>> hook
>>>> in the spice code.
>>>
>>> The thing Gerd objected to when I sent a patch doing just that was the
>>> way I used the vmstate, one possible way to not have to use vmstate at
>>> all is adding api for querying the current front end connected status,
>>> like qemu_fe_is_connected. Is that acceptable?
>>
>> To determine if the backend is connected?
>
> No to query if the front-end is connected to the guest, with virtio-ports
> just because they are there does not mean the guest is listening,
> so qemu_fe_is_connected is the right name, or maybe
> qemu_fe_is_guest_connected

Hmm, wait Alon fell for the pitfall of the somewhat weird naming of
the chardev functions, where functions which are prefixed with qemu_chr_fe
are not calls *to* the frontend, but are functions intended to be called
by the frontend (I'm used to functions being named after the subject,
not after the caller).

So what we would like to add is a new qemu_chr_be_is_fe_connected to be
called by backends to find out if the frontend is connected (iow if
the guest is actually listening to a virtio-port).

This could then be called by the spicevmc be code from a vm_change_state_handler
to find out if the guest is connected to the virtio-port post migration.

Anthony, would that be an acceptable solution?

Regards,

Hans