From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=56479 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P5i37-0001WT-E1 for qemu-devel@nongnu.org; Tue, 12 Oct 2010 12:50:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P5i33-0003Aq-Vc for qemu-devel@nongnu.org; Tue, 12 Oct 2010 12:49:59 -0400 Received: from mail-gw0-f45.google.com ([74.125.83.45]:63989) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P5i33-0003Aj-TB for qemu-devel@nongnu.org; Tue, 12 Oct 2010 12:49:57 -0400 Received: by gwj19 with SMTP id 19so1458025gwj.4 for ; Tue, 12 Oct 2010 09:49:57 -0700 (PDT) Message-ID: <4CB491B0.3050104@codemonkey.ws> Date: Tue, 12 Oct 2010 11:49:52 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/2] usb-ccid device (v2) References: <1422376658.217751286901819957.JavaMail.root@zmail06.collab.prod.int.phx2.redhat.com> In-Reply-To: <1422376658.217751286901819957.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:43 AM, Alon Levy wrote: > ----- "Anthony Liguori" wrote: > > >> 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. >> > 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