From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37250 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PKu1n-0002yR-8R for qemu-devel@nongnu.org; Tue, 23 Nov 2010 09:39:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PKu1i-0008AJ-DN for qemu-devel@nongnu.org; Tue, 23 Nov 2010 09:39:27 -0500 Received: from mx1.redhat.com ([209.132.183.28]:12791) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PKu1i-0008A3-6R for qemu-devel@nongnu.org; Tue, 23 Nov 2010 09:39:22 -0500 Date: Tue, 23 Nov 2010 16:39:13 +0200 From: Alon Levy Message-ID: <20101123143913.GA5049@playa.tlv.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Qemu-devel] usb-ccid notes for today's meeting List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Robert Relyea Hi, I've compiled the list of objections from the previous round of talks between Anthony and {Robert and I}, with our answers, for reference in todays talk (sorry about late send). Notes for KVM meeting. Points raised by anthony: 1. How does the smart card state get migrated? 2. How do you benefit from tracing and debugging qemu infrastructure? 3. Device creation is difficult, you need to launch and configure the external daemon. 4. Why not: use in qemu emulated card, and develop a protocol for connecting to the remote card. 5. I think a remote passthrough protocol who's sole purpose is to allow external device emulation is a bad idea for QEMU. 6. Security concert: possible guest breaking into spice client. Answers: 1. in emulated: isn't, there will be a different card on the new host anyway. in passthru: no need, only usb-ccid state needs migration (and that is trivial). the rest has never moved, since it is in the client. Other important notes on migration: 1. This is just like passthrough, only with the remote side staying put during migration (as noted by anthony himself). 2. We do emulate on the client side, but that is not required to participate in qemu features, it is not expected to migrate for instance, and is there to provide the locking (to allow multiple card users, qemu being one of them). 2. we don't for the passthru, we do for the usb-ccid and emulated cards. We can test usb-ccid using the emulated card. So far the only problems that were not elementary to fix were with usb layer. 3. for passthrough we already have a daemon, called spicec, which we will reuse. For emulated card this is not a problem. 4. Two protocols seems overkill, although it is doable. A second protocol not based on smart card spec may impede our future flexibility wrt new smart cards. 5. The passthrough usage for spice is to allow locking, and that requires a remote emulator. But it can be used by itself with vscclient in passthrough mode (vscclient is part of cac_card repository) and then there is no external emulation. 6. We already have an existing daemon, which needs to live with these security concerns. Alon