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@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list