Re: [libvirt] [RFC PATCHv2 5/5] WIP: smartcard: turn on qemu support
On 01/18/2011 02:14 AM, Alon Levy wrote:
> I think it is pretty easy to add one <smartcard
mode=''> per new
> backend. The toughest part would be how to query whether a given
> backend is available in a given qemu binary, but if you can please make
> sure that 'qemu -device usb-ccid,?' lists all valid backends for a given
You meant ccid-card-emulated, right? usb-ccid doesn't have backends. Looking
into existing devices, this doesn't look that difficult, It can be printed like so:
ccid-card-emulated.backend=nss-emulated/certificates/anythingelse
Correct, and thanks for picking up my intended meaning.
I'll just make sure the names I use don't contains any '/' chars :)
Actually, supplying a list of possible backends is easy. Actually testing
which are available at runtime - right now it should be identical, since if you
can't find the NSS so qemu won't pass the loading stage. But that still means
I will report nss-emulated even if there are no hardware devices. Is that
acceptable?
Yes, always listing backend=nss-emulated when it is compiled in, even
when nss will fail at runtime because there was no access to hardware,
is an acceptable solution, so long as qemu dies with a reasonable error
message in that case (there, we can chalk it up to a configuration
issue, where the admin is attempting to use a qemu feature without
supplying the correct environment, and since libvirt will relay the qemu
error message on to the user, that should be sufficient to point the
user to how to fix things).
Back to the earlier question of which backend device qemu will access in
the host, it sounds like you will need an optional <source
path='/path/to/device'/> in the XML to let libvirt know which device
needs additional permissions added to allow qemu (shared) access to that
device. It may also make sense to have an optional backend parameter,
as in:
-device ccid-card-emulated,backend=nss-emulated,path=/path/to/device
to make qemu force NSS to use the given device, rather than probing, for
the case when SELinux will cause NSS probing to fail. It would be nice
to document what device(s) are probed when the forced device path is not
present, to explain the difference between:
<smartcard mode='host'/>
and
<smartcard mode='host'>
<source path='/path/to/device'/>
</smartcard>
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 619 bytes)