Re: [libvirt] [RFC PATCHv2 5/5] WIP: smartcard: turn on qemu support
On 01/15/2011 06:30 AM, Alon Levy wrote:
> In other words a hierarchy
>
> USB bus 0
> |
> +- ccid0
> | |
> | +- smartcard0 (ccid slot 0)
> | +- smartcard1 (ccid slot 3)
> |
> +- ccid1
> |
> +- smartcard2 (ccid slot 0)
I'm okay with enforcing one-to-one correspondence for now (a ccid bus
can have at most one smartcard, always at slot 0), as long as the
resulting XML is easily extensible for any future qemu patch that allows
multiple smartcards per ccid bus.
Regarding usb-ccid bus:
1) the id is currently done by the qdev code when supplied a NULL bus parameter,
i.e. it takes the device id and appends ".0", so you get for instance:
-device usb-ccid,id=ccid0 -device usb-ccid,id=ccid1
-device ccid-card-emulated,bus=ccid0.0
-device ccid-card-emulated,bus=ccid1.0
Becomes:
bus: ccid1.0
type ccid-bus
dev: ccid-card-emulated, id ""
dev-prop: backend = "nss-emulated"
dev-prop: cert1 = <null>
dev-prop: cert2 = <null>
dev-prop: cert3 = <null>
dev-prop: db = <null>
Hmm - in the hosts-certificates mode, it looks like I need to support an
optional <database> sub-element to populate the ccid-card-emulated.db
field when desired. Is that field a pathname, a generic arbitrary
string, or something else altogether?
dev-prop: debug = 0
bus-prop: slot = 0
That is, bus can be inferred (take the ccid device and append .0) if
omitted in the user's XML, but will be explicitly supplied in the
command-line generated by libvirt in case qemu ever allows a non-zero
bus-prop: slot in the future.
Tell me if this needs to be changed - for instance I could just
reuse the id as the bus name, so it will lose the ".0" suffix.
I think keeping the .0 suffix allows you the future ability to support
multiple cards on a single bus.
2) usb-ccid device doesn't support more then one slot atm. This
may be changed later, but atm to create two slots you need two
busses. Also, this is a bug, two emulated slots will probably
fail (haven't tested), since I'm pretty sure I'm doing all
the initialization twice in that case, and even if not, my
event quering loop doesn't have a concept of a target, so
some events will end up at the first, some at the second - chaos.
The good news is that this is totally opaque to libvirt, just
an implementation bug.
Should libvirt enforce at most one smartcard until this is fixed in
qemu, or should I go ahead and assume that smartcard won't be accepted
into upstream qemu until after issues like this have been resolved?
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 619 bytes)