Re: [libvirt] [RFC PATCHv2 5/5] WIP: smartcard: turn on qemu support
On Mon, Jan 17, 2011 at 11:30:38AM -0700, Eric Blake wrote:
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?
Pathname is the only thing I've tested, so let's limit it to this. It's
NSS specific right now too - but as you see from the arguments it will probably
be orthogonal, for instance under windows there might be a cryptoapi-emulated
backend and db argument will be reused.
> 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.
The question was about changing my behavior, since right now I rely on
the default qemu behavior of appending that ".0". So I understand you
will supply that as a string bus=<id>.0, and since I actually ignore that
but qemu computes the same bus id, it will just work.
>
> 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?
The former. Since it hasn't been accepted yet, it may become the later (I
guess I'll have to do it sooner or later).
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org