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
