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

[Alon Levy]

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

Regarding the method of reconnection: You are absolutely right that if I have 
qemu
connect to the remote instead of the other way around then I remove the need to 
inform
vscclient of the new address. But the way it stands requires the client to know 
the
address of the destination qemu. I have to inform it somehow. You are saying 
that
devices shouldn't know this information? ok, that's why I talked about monitor 
commands.
I come from the world of spice - in spice we use monitor commands for this. I 
could
change this to have qemu connect to vscclient, but I don't see the logic in 
general -
sometimes you do want to have a chardev that is listening (the fact that it is 
implemented
suggests someone found it useful), if you then migrate you have the same 
problem I'm
solving.

> Regards,
> 
> Anthony Liguori
> 
> > Alon Levy (2):
> >    usb-ccid: add CCID device. add configure option.
> >    usb-ccid: add CCID device (device itself)
> >
> >   Makefile.objs      |    1 +
> >   configure          |   12 +
> >   docs/usb-ccid.txt  |  115 +++++
> >   hw/usb-ccid.c      | 1376
> ++++++++++++++++++++++++++++++++++++++++++++++++++++
> >   hw/vscard_common.h |  131 +++++
> >   5 files changed, 1635 insertions(+), 0 deletions(-)
> >   create mode 100644 docs/usb-ccid.txt
> >   create mode 100644 hw/usb-ccid.c
> >   create mode 100644 hw/vscard_common.h
> >
> >