Re: [libvirt] adding smartcard support to libvirt

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(a)redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org