[libvirt] adding smartcard support to libvirt

[Eric Blake]

On 01/04/2011 02:17 AM, Alon Levy wrote:

[focusing on the spicevmc chardev aspect]

>>
>> <domain...>
>>   <devices>
>>     <smartcard mode='passthrough' name='xyz'>
>>       <serial type='spicevmc'/>
>>     </smartcard>
>>   </devices>
>> </domain>
>>
>> maps to qemu -chardev spicevmc,id=smartcard,name=xyz -usb -device
>> usb-ccid -device ccid-card-passthru,chardev=xyz
>>
> 
> ok, here you just mixed the id and name. I admit name is a bad, well, name,
> but it was already available as a parameter to chardev's (used as the filename
> for a file chardev). In the context of a spicevmc chardev the name is actually
> what I internally call a subtype. There are two subtypes/names that are valid
> currently: vdagent and smartcard. The id attribute is a global qemu tag that
> identifies a particular instance, so what needs to match is the chardev id
> and the chardev value given to the ccid-card-passthru device:

> 
>> And, given the goal that <smartcard mode='passthrough'> then has a child
>> element that describes the passthrough device, it also means that I
>> would be adding support for a top-level spicevmc chardev device,
>> unrelated to smartcards; would this need any additional XML parameters?
>>
> 
> Right, again sorry for introducing it this way - exactly correct, the spicevmc
> is a separate entity. It is a new chardev, this is the chardev suggested last
> time I talked to libvirt when I tried to introduce a similarly named device
> called spicevmc. So instead of a superficial wrapper around virtio-serial I
> am introducing a chardev that can be used to connect to the spice server that
> is linked to the qemu process. The parameters for spicevmc are:
> id - this is the normal identifier that all chardev's must have.
> name - this distinguishes between the use of this chardev internal to spice, it
>  can be of two values right now as I mentioned, 'vdagent' for use as the vdagent
>  connection, and 'smartcard' for use by the smartcard channel.
> 
>> <domain...>
>>   <devices>
>>     <serial type='spicevmc'>
>>       <!-- anything else needed for a top-level spicevmc chardev? -->
>>     </serial>
>>   </devices>
>> </domain>
>>
> 
> <serial type='spicevmc' id='xyz' name='vdagent'/>
> <serial type='spicevmc' id='xyz' name='smartcard'/>

According to our existing XML:
http://libvirt.org/formatdomain.html#elementsConsole

there are four categories of chardevs: <serial>, <parallel>, <console>,
and <channel>.  Within each chardev, there are two optional
sub-elements: <source> describing the host's view of the chardev, and a
<target> describing the guest's view (the chardev type dictates whether
<source> must exist, and the chardev category dictates what <target>
must look like).

It sounds to me like spicevmc is best described as a <channel>, since it
is exposing a spice channel for host communications rather than an
actual character device on the host.

The chardev type of spicevmc (the type attribute under
<serial|parallel|console|channel>) does not fit in with any of the
existing channel types of 'stdio', 'file', 'vc', 'null', 'pty', 'dev',
'pipe', 'tcp', 'udp', or 'unix', so it would be a new type 'spicevmc'.
It probably only makes sense to use type='spicevmc' with <channel>, so
the other three chardev types should probably reject it.

When the chardev type is 'spicevmc', the <source> sub-element seems like
it is optional (since the spice connection has sane defaults), but if
provided, will provide the extra information that can also be provided
through the existing <graphics type='spice'> element, such as port='5903'.

Meanwhile, since spicevmc is a <channel>, the <target> element must
specify a type (right now, the only types expected for <channel> are
'guestfwd' and 'virtio'), so we're effectively adding two new types
('vdagent' and 'smartcard').

So, I'm thinking that this XML representation matches the spicevmc chardev:

<devices>
  <channel type='spicevmc'/>
    <source port='5903' tlsPort='5904' autoport='no'
listen='127.0.0.1'/>
    <target type='smartcard'/>
  </channel>
</devices>

In looking more at libvirt XML, I don't see any fields that match id
assignments; rather, libvirt auto-assigns unique ids in the form %s%d,
category, count, where category matches <channel> and count matches how
many <channel> devices are present.  That is, the above xml would map to:

qemu -chardev spicevmc,id=smartcard,name=channel1


Hmm; getting spicevmc to work seems independent enough of getting
<smartcard> implemented by using existing <channel type='tcp'/>, so I'll
try to split my libvirt XML improvements into two batches.  Should I
focus on <channel type='spicevmc'> or on <smartcard> first?

-- 
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/20110105/fb69704b/attachment-0001.sig>