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: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 0/2] usb-ccid device (v2)
Date: Tue, 12 Oct 2010 11:49:52 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Lightning/1.0b1 Thunderbird/3.0.8

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?

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




reply via email to

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