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