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

[Alon Levy]

----- "Anthony Liguori" <address@hidden> wrote:

> On 10/12/2010 11:43 AM, Alon Levy wrote:
> > ----- "Anthony Liguori"<address@hidden>  wrote:
> >
> >    
> >> On 10/12/2010 11:03 AM, Alon Levy wrote:
> >>      
> >>> ----- "Anthony Liguori"<address@hidden>   wrote:
> >>>
> >>>
> >>>        
> >>>> On 10/12/2010 07:58 AM, Alon Levy wrote:
> >>>>
> >>>>          
> >>>>> This patch adds a new device, it is described in full in the
> >>>>>            
> >> second
> >>      
> >>>>>
> >>>>>            
> >>>> patch
> >>>>
> >>>>          
> >>>>> intro and also in the documentation in docs. In brief it
> provides
> >>>>>            
> >> a
> >>      
> >>>>>
> >>>>>            
> >>>> standard
> >>>>
> >>>>          
> >>>>> smart card reader device.
> >>>>>
> >>>>> The first patch is the configure change and docs.
> >>>>> The second patch contains the actual device, I couldn't figure
> out
> >>>>>            
> >> a
> >>      
> >>>>>
> >>>>>            
> >>>> good
> >>>>
> >>>>          
> >>>>> way to split it to ease review.
> >>>>>
> >>>>> v2 changed:
> >>>>>     * all QSIMPLEQ turned into fixed sized rings
> >>>>>     * all allocated buffers turned into fixed size buffers
> >>>>>     * added migration support
> >>>>>     * added a message to tell client qemu has migrated to
> ip:port
> >>>>>      * for lack of monitor commands ip:port are 0:0, which
> causes
> >>>>>            
> >> the
> >>      
> >>>>>
> >>>>>            
> >>>> updated
> >>>>
> >>>>          
> >>>>>       vscclient to connect to one port higher on the same host.
> >>>>>            
> >> will
> >>      
> >>>>>
> >>>>>            
> >>>> add monitor
> >>>>
> >>>>          
> >>>>>       commands in a separate patch. tested with current setup.
> >>>>>
> >>>>>
> >>>>>            
> >>>> This is way too much magic to live within a device.  Devices
> >>>>          
> >> manage
> >>      
> >>>> reconnecting themselves during migration.  When you create the
> >>>> destination qemu instance, you specify what to connect to.
> >>>>
> >>>> IOW,
> >>>>
> >>>> On the source:
> >>>>
> >>>> qemu -chardev tcp:localhost:1025,id=foo -usbdevice
> >>>>          
> >> ccid,chardev=foo
> >>      
> >>>> ...
> >>>>
> >>>> On the destination:
> >>>>
> >>>> qemu -chardev tcp:localhost:1026,id=foo -usbdevice
> >>>>          
> >> ccid,chardev=foo
> >>      
> >>>> -incoming tcp:0.0.0.0:1024 ...
> >>>>
> >>>> A connection happens when the device is created.
> >>>>
> >>>> But now I'm even further confused then when I first reviewed
> it..
> >>>>          
> >> If
> >>      
> >>>> you're now supporting migration, does that mean that you're
> relying
> >>>>          
> >> on
> >>      
> >>>> the daemon to emulate the device?
> >>>>
> >>>>
> >>>>          
> >>> Let me try to clarify this. Nothing has changed since the last
> patch
> >>>        
> >> except
> >>      
> >>> for what's in the notes, i.e. migration support. The device I'm
> >>>        
> >> adding is a
> >>      
> >>> reader. The reader is just a pipe between smart cards and the
> guest
> >>>        
> >> operating
> >>      
> >>> system. The smart card logic does live outside of this device,
> and
> >>>        
> >> is available
> >>      
> >>> in the cac_card sources at
> >>>        
> >> http://cgit.freedesktop.org/~alon/cac_card/ (all of
> >>      
> >>> this is in docs/usb_ccid.txt).
> >>>
> >>> So when I speak of vscclient, I'm talking of an application that
> >>>        
> >> emulates a smart
> >>      
> >>> card and initiates a tcp connection to qemu that connects to the
> >>>        
> >> usb-ccid device.
> >>      
> >>> vscclient is also in the cac_card sources.
> >>>
> >>>        
> >> Okay, let me be clear.  We shouldn't be doing device emulation
> outside
> >>
> >> of QEMU's source tree--at least, not in this type of context.
> >> External
> >> devices present a great deal of challenges and we shouldn't just
> >> approach it in an ad-hoc fashion.
> >>      
> > There are two devices:
> >   smart card reader, aka CCID device - emulated inside qemu.
> Submitted.
> >   smart card - emulated outside of qemu. Fully available, open
> source separate project.
> >    
> 
> And how does the smart card state get migrated during migration?  How
> do 
> you keep it synced with QEMU?
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).

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