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

[Eric Blake]

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 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/20110118/9f9c5eba/attachment-0001.sig>