qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Hans de Goede
Subject: Re: [Qemu-devel] [PATCH 1/4] char: add a post_load callback
Date: Thu, 21 Mar 2013 09:36:10 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4

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 <address@hidden> writes:

Alon Levy <address@hidden> writes:

Signed-off-by: Alon Levy <address@hidden>
---
  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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]