[libvirt] adding smartcard support to libvirt

[Alon Levy]

On Wed, Jan 05, 2011 at 12:25:58PM -0700, Eric Blake wrote:
> 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'/>

I got you until now - but what's with the port/tlsPort - all of that stuff belongs
to the spice flag, and I'm pretty sure is already taken care of by some other
tag (I guess <spice> probably?). This chardev is totally separate (sure, you need
to be using spice for it to make sense, but there is not overlap in parameters, for
instance you don't give a port nor a tlsPort to the spicevmc chardev).

>     <target type='smartcard'/>
This looks right.

>   </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
> 
I hope you meant id=channel1,name=smartcard ? the id needs to be the same
as the ccid-passthru uses. But I guess we determined that it's easiest to
let the <smartcard mode="passthru"/> already add the spicevmc chardev
itself? the usage of "-chardev spicevmc,id=xyz,type=smartcard" is only
for a "-device ccid-card-passthru,chardev=xyz", so one won't appear without
the other.

The usage of "-chardev spicevmc,id=xyz,type=vdagent" is also just with the
usage of spice, I'm guessing the existing <spice> tag (sorry, not familiar
with it - I use qemu from shell scripts.. :/ ) should just always create
this chardev, and libvirt will make sure it's id doesn't conflict with any other,
i.e. for spice usage a spicevmc chardev used by a virtioserialport device:

 -chardev spicevmc,id=chardev1,name=vdagent -device virtserialport,chardev=chardev1,name=com.redhat.spice.0

This creates the virtioserialport device with the name the in-guest agent looks for, and ties it
to the correct spice server interface via the spicevmc chardev.

> 
> 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?

I guess start with the smartcard first? Implement it without dealing
with the spicevmc side - i.e. don't implement the passthru type first,
or propose it but don't implement it. Then do the spicevmc part.

I'm not particular on the order - both are required for RHEL 6.1 anyhow,
and each is testable without the other (spicevmc with vdagent usage outlined
above, and smartcard without spice by using it locally through libvirt).

> 
> -- 
> Eric Blake   eblake at redhat.com    +1-801-349-2682
> Libvirt virtualization library http://libvirt.org
>