Hi,
On 03/15/2012 03:22 PM, Alon Levy wrote:
On Thu, Mar 15, 2012 at 01:36:23PM +0100, Hans de Goede wrote:
Hi,
On 03/15/2012 01:11 PM, Yonit Halperin wrote:
On 03/13/2012 09:40 AM, Gerd Hoffmann wrote:
Hi,
It is not easy when you have 2 components, and it is much less easy when
you have 3 or 4 components. So why make it more complicated if you can
avoid it. Especially since there is no functional reason for making the
qemu/client capabilities/versions dependent on the server internal data.
qemu has ways to handle compatibility in the vmstate format. We can use
those capabilities. That of course requires exposing the structs to be
saved to qemu and adds some complexity to the qemu<-> spice interface.
What session state is needed by the target?
What of this can be negotiated between client and target host without
bothering the source?
What needs be transfered from source to target, either directly or via
client?
If this is a hard requirement then using the vmstate channel isn't going
to work. The vmstate is a one-way channel, no way to negotiate anything
between source and target.
We can do this via the client.
Then you can send the actual state via client too.
Out-of-band negotiation for the blob send via vmstate scares me.
Can we please start with a look at which state we actually have to send
over?
Ok, I can take the display and sound channels.
Alon, can you take the smartcard?
Smartcard is actually using spicevmc state in qemu as well - the qemu
part is the same as the usb part, uses spicevmc chardev. And there is
already vmstate for the ccid-card-passthru device. In flight messages
can be dealt with the same way Hans suggested for spicevmc channel as
well.
The channel itself has a buffer it needs to save unless we go the same
route Hans suggested and flush it. IIRC there are messages for doing
that in the protocol already - server asks client to get ready for
migration, client notifies server when it is ready. Server can pass all
messages it has to write to client before sending it PREPARE_TO_MIGRATE,
then it can push anything it gets from the client to qemu (hmm, that
could take an undefined amount of time if spicevmc/usb ccid are not
processing it fast enough), while not polling qemu for new stuff, and
the client shouldn't be sending anything new anyway after the
PREPARE_TO_MIGRATE.
There seems to be more state in spice/server/smartcard.c then just
buffers, ie if a reader is attached or not. Then again that seems
to reflect whether a client is connected to the channel or not,
so you're probably right.
Hmm, interesting you allow for multiple smartcard chardevs in theory,
but then in smartcard_char_device_add_to_readers you unconditionally
call smartcard_init which does:
SmartCardChannel *g_smartcard_channel;
static void smartcard_init(void)
{
ChannelCbs channel_cbs = { NULL, };
ClientCbs client_cbs = { NULL, };
ASSERT(!g_smartcard_channel);
<snip>
g_smartcard_channel = (SmartCardChannel*)red_channel_create(sizeof(...
So in essence you allow only 1 smartcard chardev, and registering a
second will trigger the ASSERT (if enabled), or override
g_smartcard_channel ...
Not really migration related just something I noticed.
Regards,
Hans
_______________________________________________
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
