[libvirt] [RFC PATCHv2 5/5] WIP: smartcard: turn on qemu support

[Eric Blake]

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 at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20110117/6b38cad3/attachment-0001.sig>