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. > >Hans, spicevmc? > > Easy, the spicevmc channel has no state which needs to be migrated, except > for things in the red_channel_client base class: > > 1) Partially received spice messages > 2) Possible pending pipe items when writes from qemu -> client have blocked. > > I assume that the red_channel_client base class will handle migrating them, > if we migrate them at all. > > Instead of migrating we could: > For 1. expect the client to stop sending new messages at a certain point > during the migration, and ensure we've processed any pending messages > after this point. > > For 2. we could flush pending items and set a flag to stop channel > implementations from queuing new ones, at which point for spicevmc the > data will get queued inside qemu and migrating it no longer is > a spice-server problem to migrate it (and we need migration support for > the data possibly queued inside qemu anyways). > > Regards, > > Hans _______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
