Re: [Qemu-devel] [PATCH 0/2] usb-ccid device (v2)

[Anthony Liguori <anthony@codemonkey.ws>]

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.

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
>>