From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=43139 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P5hbX-0001Zr-Ef for qemu-devel@nongnu.org; Tue, 12 Oct 2010 12:21:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P5hbU-0007XW-GP for qemu-devel@nongnu.org; Tue, 12 Oct 2010 12:21:30 -0400 Received: from mail-qw0-f45.google.com ([209.85.216.45]:58508) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P5hbU-0007XD-Cu for qemu-devel@nongnu.org; Tue, 12 Oct 2010 12:21:28 -0400 Received: by qwh5 with SMTP id 5so1958007qwh.4 for ; Tue, 12 Oct 2010 09:21:27 -0700 (PDT) Message-ID: <4CB48B04.6040905@codemonkey.ws> Date: Tue, 12 Oct 2010 11:21:24 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/2] usb-ccid device (v2) References: <1218420653.213741286899380859.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com> In-Reply-To: <1218420653.213741286899380859.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alon Levy Cc: qemu-devel@nongnu.org On 10/12/2010 11:03 AM, Alon Levy wrote: > ----- "Anthony Liguori" 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. I'm not opposed to passthrough although I'd prefer QEMU to talk to the 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. 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 >>> >>> >>>