qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alon Levy
Subject: Re: [Qemu-devel] [PATCH 0/2] usb-ccid device (v2)
Date: Tue, 12 Oct 2010 12:43:39 -0400 (EDT)

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

The idea here is to allow a remote device to be accessed from the guest. The
remote device is not running necessarily on the qemu host, so there has
to be a network connection, which implies some remote client. The only thing
that is changeable is where the card is emulated - at the client side or at qemu
side. I understand you favor qemu. But really this is not that much of a change
as you imply, and there is a good reason for having it on the client side, 
namely
latency of talking to the real card reader. Even if it was local to qemu, it 
would
still have to wait for responses from the network, so I don't see how it would 
be
less fragile.

I don't think the device right now is done ad-hoc, but you are welcome
to comment on anything specific (it is up for review).

(sorry for repeating myself, I guess what follows is the main point): The CCID 
device is a standard USB
class device, some of the USB events are handled without access to the network, 
and some
result in a write to the chardev (==network), which is recorded, and when a 
read from
the chardev happens some resulting USB activity happens. It is not yet without 
errors, but
it is stable, passes migration, and works most of the time. The only exception 
are occasional short
packets that I am still investigating, and hope won't prevent a review of the 
current status.

> 
> I'm not opposed to passthrough although I'd prefer QEMU to talk to the
> 

passthrough I'm familiar with are all on the same host QEMU is running on,
that goes for pci and usb passthrough (afaik those are the only ones).

> device directly instead of going through a daemon.
> 
> There's a lot of delicate integration between QEMU and a device and if
> a 
> device lives outside of QEMU, it makes it extremely difficult for us
> to 
> influence changes to that device to support QEMU new features.
> 
> > 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.
> 
> And none of that is upstream.
> 

You only replied to the last part. What is your suggested fix for this case:

1. qemu -chardev socket,server,host=0.0.0.0,port=2001,id=foo,nowait -device 
virtioserial-port,chardev=foo
2. app X connects to 2001 from clienthost
3. migrate to otherhost running on otherport
 otherhost$ qemu.. <same commandline, 2001 replaced with otherport>
4. X is left hanging

I realize it seems a contrived example, but I imagine the socket,server option 
is actually used like this, otherwise
what is it there for?

> Regards,
> 
> Anthony Liguori
> 
> >   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
> >>>
> >>>
> >>>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]