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

[Anthony Liguori <anthony@codemonkey.ws>]

On 10/12/2010 11:43 AM, Alon Levy wrote:
> ----- "Anthony Liguori"<anthony@codemonkey.ws>  wrote:
>
>    
>> On 10/12/2010 11:03 AM, Alon Levy wrote:
>>      
>>> ----- "Anthony Liguori"<anthony@codemonkey.ws>   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?

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?

Regards,

Anthony Liguori