----- "Anthony Liguori" <anth...@codemonkey.ws> wrote: > On 10/12/2010 12:09 PM, Alon Levy wrote: > > The smart card is not being migrated. It is running on the client > machine, > > which is not being migrated/shutdown (same as vncviewer isn't > migrated). > > > > > > Ok, let's look at this compared to another similar use-case: USB > passthrough of a webcam device that's remoted using USB over IP. > > In this model, you have a USB bus that's modelled as a bus and a > device. Within the USB bus, you have additional devices. These are > all > qdev devices and they may be emulated or they may be implemented using > > passthrough. While we don't do it today, USB over IP would be just > another form of passthrough. > > Migration is a rather interesting challenge in this model. You've got > a > mix of client state and server state on the USB over IP connection. > You > could marshal up the client state and as long as you reconnected to > the > same server on the destination, I guess it would be okay. > > I think the problem with your current implementation is that you've > completed skipped the bus modelling and you're also using the Device > over IP connection to implement device emulation. > > What I would suggest is that you model the bus/device relationship via > > qdev and move the Smart Card emulation into QEMU. I would also > suggest > adding proper passthrough support in QEMU. CCID over IP is a > reasonable > thing to have but I think you've got way too much outside of QEMU > right > now such that long term maintenance is going to be exceedingly > difficult. >
CCID over IP doesn't make any sense (It's just a specific sort of reader), but I assume you meant APDU (the smart card protocol) over IP, which is exactly what vscard_common.h protocol has (so that's already ready). I'll address the modeling of the reader device as a bus and add optional card emulation. You can regard the current implementation as exactly passthrough of APDU, that's what it does - pushes the APDU's to a remote client, and gets APDUs in return. Since I'm using an existing library for the card emulation I will make qemu link with it. Alon > Regards, > > Anthony Liguori > > >> I don't understand the use-case behind this. Is this so that a > local > >> > >> physical smart card can be passed through to a guest from a Spice > >> client > >> and when migration happens, the QEMU instance connects back to the > >> Spice > >> client? So the device is never actually migrated? > >> > >> > > The *smart card* is never migrated. The ccid device is. Here is the > scenario: > > > > Host A: qemu_a > > qemu_a: guest > > > > Host B: vscclient > > - physical reader > > > > Host C: qemu_b -incoming .. > > > > yes, we will use this for SPICE, but this is submitted > > to qemu on the hopes and with testing ensuring it is perfectly > usable as is > > without using SPICE, otherwise I wouldn't have sent it upstream. > > > > non-SPICE usage: > > > > 1. user on B runs vscclient (and presumably the user has some > connection to the guest to use the smartcard device, i.e. > vnc/ssh/spice, but that's not relevant). > > 2. vscclient connects via tcp to qemu_a. > > 3. qemu_a starts migrating to qemu_b. > > (qemu_b is alive at this point, can receive incoming tcp > connections on chardev - otherwise a migration fails immediately > anyway) > > 4. pre_load for usb-ccid sends a Reconnect message > > 5. vscclient gets the Reconnect message, closes socket to qemu_a, > opens socket to qemu_b > > 6. from guest pov nothing happened (no device detach/attach). > > > > I have to stress that the main problem the migration intends to > solve is to avoid a detach/attach in the guest. Actual > > operations on the smartcard could possibly fail as a result of the > migration, and it would not be a real problem (i.e. > > we could live without, but we can't leave with a lock of the guest > screen as a result of a migration). Which is why I > > consider the current code good enough. It is certainly not perfect > (short packet issue), or tested enough. > > > > The SPICE usage scenario is basically the same, just replace > vscclient with spicec, and > > we don't need the Reconnect message since SPICE takes care of this > for us (we just get > > a channel detach/attach event if we care). > > 1. user on B runs spicec > > 2. spicec connects to qemu via spice channel, smart card channel > connects to usb-ccid device via spicevmc chardev (so it doesn't care > it's spice or not). > > 3. qemu_a migrates > > 4. spicec disconnects from qemu_a and connects to qemu_b > > 5. from guest os pov nothing happens on the ccid usb device. > > > > > >> Regards, > >> > >> Anthony Liguori > >>
