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

[Alon Levy]

----- "Anthony Liguori" <address@hidden> 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
> >>